1、水平触发模式下发送数据深度解释
当请求处理的最后，往往需要往客户端发送数据。
当从连接读完数据并处理后，需要把感兴趣的可写事件增加到连接中。
什么叫socket可写？
每一个tcp连接（socket），服务器这段都会对应一个接收缓冲区和一个发送缓冲区。
发送缓冲区缺省大小一般是十几K，接收缓冲区大概有几十K。setsocketopt（）设置大小。
当调用send，write发送数据，是把数据放到了发送缓冲区。内核尝试往客户端发送数据。当客户端recv，read收到数据并且告诉服务器收到之后。服务端才会从发送缓冲区干掉这些已经确认的数据。然后服务器可以再次往发送缓冲区里面写。所以客户段需要快速read走数据，要是网卡陈旧，接收数据慢，发送端缓冲区满的话，服务器再调用send，write就会返回一个错误：EAGAIN...示意服务器等一会重发。
应对方案：
1）、最普遍的解决方案：需要向socket写数据的时候，再加入写事件到epoll对象中。等待可写事件，操作系统会通知，此时可以调用write/send发送数据，当发送数据完毕后，把socket的写事件通知从红黑树中移除。缺点在于：即使发送很少的数据，也需要把事件通知加入到红黑树。写完毕后还要干掉。对效率有一定的影响。
2）、改进方案：开始不把写事件通知加入到epoll，当需要写数据的时候，直接调用write直接发送，如果返回了EAGAIN，此时再把写事件通知加入到epoll。此时就变成了在epoll驱动下写数据，等全部数据发送完毕之后，再把写事件通知痛epoll中干掉。
优点：数据不多的时候可以避免epoll红黑树中写事件的增加或者删除。

2、gdb调试浅谈
设置了socket写事件放到epoll中之后，水平触发模式下，当socket可写的时候，会触发socket可写事件，意味着只要发送缓冲区未满，问题在於就会不停的触发可写事件。
当不停的触发可写事件的时候，如果客户端再次发送注册事件过来，此时worker进程down掉了。。因为第二次调用事件处理时又加了可写事件进epoll对象，这就造成了重复，worker进程崩溃。怎么调试呢？
gdb调试只是在不熟练的时候使用，当成了大师，增加打印日志一般就可以解决问题。程序崩溃问题可以借助gdb调试找到崩溃行。在错误能够重现的时候还好。不能够重现的问题比较麻烦。
gdb调试，需要编译时需要带个-g选项编译，尽可能使用root权限su。
当前目录开始执行：gdb nginx
gdb缺省调试主进程，7.0以上版本可以调试子进程。gdb -v 看版本。
为了让gdb进行多进程调试，要设置一下follow-fork-mode选项，这个是调试多进程的开关。
赋值可以是parent/child，设置成child调试子进程。
查看follow-fork-mode当前值：gdb命令行输入：show follow-fork-mode
输入：set follow-fork-mode child设置child
还有一个detach-on-fork选项 ,默认是on，表示只调试父子进程其中的一个，由上一个选项决定调试哪一个进程。如果为off，那么父子进程都可以调试。调试其中一个，另外一个进程就会被暂停，如果follow-fork-mode为parent，那么fork出来的子进程并不运行，暂停。

设断点：b logic/ngx_c_slogic.cpp:198
运行到断点：run
发包，运行到断点停下，
打印变量值：p xxx
继续运行：c
就进入不断的触发可写事件。
再一次发包，worker进程进入崩溃，gdb打印段错误信息。就可以定位到段错误的行。
（this->*(c->rhandler))(c)
问题原因：往红黑树增加的时候绑定了有效数据，在MOD的时候没有绑定。

tL状态：追踪器件被调试器终止，有些页面被锁在内存。
退出：quit