你这一套搞的太复杂了, 完全是公司服务器的作风. 我自己服务器上所有在跑的程序都是裸 go, 清爽的不要不要的

这种不知所谓的文章居然看完了. 首先佩服作者的勇气, 其次希望作者多看书, 等你大学毕业就会发现你在今天干了一件什么蠢事.

试了下编译器优化, 准备好板凳:

```c
int main() {
int s = 0;
for (int i = 0; i <= 100; i++) {
s += i;
}
return s;
}
```

```sh
$ gcc -o main -O3 main.c
```

```sh
$ objdump -d main

00000000000004f0 <main>:
4f0: b8 ba 13 00 00 mov $0x13ba,%eax <----------- 0x13ba == 5050
4f5: c3 retq
4f6: 66 2e 0f 1f 84 00 00 nopw %cs:0x0(%rax,%rax,1)
4fd: 00 00 00
```

所以我觉得最好的答案是 return 5050, 因为你已经在写代码的时候就做了编译器优化...

看 c 代码经常能看到 "我知道我在做什么" 的注释然后强制跳过编译器语法检查的…

个人看来这些规范，范式可以拿来用，但不必当教条，适合自己的开发习惯就好。

正常 endian 的逻辑，一般直接强制内存类型转换会快很多

端午牛逼

毕竟如果不每半年改个版公司就会发现有些职位似乎可以不要...

现在还记得第一次编译 llvm 时花了 39 小时。。。目前的话折腾了个云服务器，编译工作就扔上去不会中断本机的工作

close 是一个系统调用, 它出错的情况只有:

```
ERRORS
The close() system call will fail if:
[EBADF] fildes is not a valid, active file descriptor.
[EINTR] Its execution was interrupted by a signal.
[EIO] A previously-uncommitted write(2) encountered an input/output
error.
```

程序中经常遇到的是 EIO, 也就是在在 close 之前, read/write 已经报错了(比如文件 fd 已经提前关闭, 网络的话 TCP 连接已经断开等), 这种情况忽略 close 的 err 才是正确的逻辑. **因为调用 close 的核心目的是释放资源, 而不管在这次调用之前资源是否已经被释放了, 程序只保证在该次调用 close 后资源一定是已经释放的状态即可.**

=服务器前面挂一个反向代理, 反向代理里限制一下并发数就好了.

支持自己动手玩一下, 学一学 parser 和 compiler 也是好的.

水冷普遍噪音比风大，降温效果不如风，价格也更高…

net/http 标准库

RTFD

@testsun 备案了, 当时花了一个月, 很烦躁

节制点用的话还行, 我最早的博客就在 1M 的服务器上, 后来写博客几篇文章中加了 gif 来展示算法, 就不行了, 现在博客还在服务器上, 但图片和 GIF 走又拍云的 CDN, 非常便宜.