这几天用多线程

系统正式开发有大半个月了，由于有非常多的loader需要同时运行，所以选择多线程来实现。伺服进程M首先创建若干个S进程；如果有服务请求到达，M创建服务线程E。E和S之间用FIFO用以传递数据。当有数据到达之后，E通过FIFO传给S，S启动一个线程Loader（Loader和S之间也是FIFO）。由于Mysql的loader命令如果成功执行的话是一直阻塞的，只有出错的时候才立即返回，所以S主线程和loader线程很不好同步。所以我已开始使用block模式操作S与loader之间的FIFO出现了问题。当loader应为mysql的表没有创建好的时候立即出错返回，之后S才以默认block的方式打开FIFO，导致S一直阻塞在open操作上；S一阻塞，导致同样是以默认方式打开FIFO的E线程也被阻塞；E一阻塞，服务器端没有人去服务socket，导致客户端也被阻塞在send上面。 唉，真是惨啦！

当初我也是意识到阻塞模式读可能会有问题，所以特别小心的处理各个线程的启动问题，没有想到还是阴沟里面翻船了。不喜欢非阻塞模式是因为不喜欢去一遍遍的处理EAGAIN错误。

尝试了一种解决方案：1. 以O_WTONLY和O_NONBLOCK模式打开FIFO，这是如果读端没有准备好，会返回错误--没有此设备，忽略掉此错误，并检查是否loader线程是否已经退出。成功打开之后调用ioctl设置写模式，但是查看ioctl的man页后发现不支持设置NONBLOCK，只好作罢；2. open的方式不变，write也是以非阻塞模式写，但是读端仍然采用阻塞模式。

粗略的试了一下2，没有问题，明天还得用UT测试一下才行。

1）线程不存在继承关系，所以他退出的时候创建者并不能获得通知，其他的线程可以用join方法取得其退出状态。如果没有被join，那么他的状态犹如zombie进程；但是线程可以被设置为deattached，这样它退出的时候就会释放资源；

2）condition的signal方法存在丢失的问题：如果signal的时候没有线程处在wait状态，那么signal不起作用；

3）NON_BLOCK模式读FIFO的时候行为？