SPProcPool: Unix/Linux 上的进程池服务器框架(增加类似 apache 的 worker模型)

iunknown

原帖由 queue 于 2007-12-25 22:57 发表

另外，在处理 MaxIdleProc 上，在 LF 模型中，好像不是严格精确的吧？
当 parent 发送 CHAR_EXIT 给 child 的时候，这个时候，如果 child 阻塞在 accept 中，那么 child 是不会退出的

嗯，的确有这样的问题。就目前看到的解决办法由两个：
1.就是 tinyproxy 的方法
2.在 parent 和 child 之间用类似 apache 的 POD （pipe of death）。
  POD 和现在 spprocpool 中，parent 和 child 之间的 pipe 不同。不是一个 child 一个 pipe ，是所有 child 共用一个 pipe 。
  这样当 parent 往 pod 写一个 CHAR_EXIT 的时候，是有可能被所有的 child 读到的（仅仅是可能，最终还是只有一个读成功了）。
  这样可以避免上面提到的问题。不过仍然有可能不够精确，在 parent 往 pod 写 CHAR_EXIT 的时候，可能所有的 child 都已经阻塞在 accept 上了。
  按这样来看，目前 apache 的实现应该也会存在这样的问题。不过出现的几率应该不是很高。并且即使出现了，影响也不是很大。

相对来看，比较倾向于用 apache 的 POD 方式。用 pipe 的方式主要是在于“干净”，不需要外在的依赖，也就不会带来冲突。
主要是一旦使用了 filelock 或者 信号量，就引入了一个外在的依赖。filelock 需要有一个文件名，信号量需要有一个 key 。
另外当 child 被强行 kill 的时候，如果使用的同步手段不能够自动恢复，那么就会死锁。
filelock 和 信号量都有进程如果异常退出，那么自动解锁的功能。mutex 就没有。

iunknown

0.4 版使用 PipeOfDeath 改进了 MaxIdleProc 的控制。
同时增加了可选的 accept locking 机制：filelock 或者 mutex 。
http://spprocpool.googlecode.com/files/spprocpool-0.4.src.tar.gz

drog1983

先保存,日后再研究!!

iunknown

这个模型在 Leader/Follower 模型的基础上，在每个进程内部使用了一个线程池，可以提高同时并发的连接数。
http://spprocpool.googlecode.com/files/spprocpool-0.5.src.tar.gz

iunknown

看了 apache 的分析文章之后，觉得里面的图非常好地描述了 apache 的结构。也尝试用 visio 画一下 spprocpool 的结构。

对图中各个部分的说明：
1. MasterServer 通过 Fork 创建 ProcessManager ，ProcessPool 作为 ProcessManager 在 MasterServer 中的存根
2. 在 ProcessPool 和 ProcessManager 之间存在一个 ManagerPipe 管道
3. 当 MasterServer 需要更多的子进程的时候，MasterServer 通过 ProcessPool 对象向 ProcessManager 发起创建 ChildServer 的请求
4. ProcessManager 是创建 ChildServer 的唯一一个地方
5. 在 MasterServer 和 ChildServer 之间存在一个 ChildPipe 管道
6. MasterServer 只负责监控子进程的状态（包括：忙、闲、异常退出），监控子进程的状态完全是通过 ChildPipe 来进行的；MasterServer 使用 select 可以同时监控所有的 ChildPipe 的可读状态；当一个 ChildPipe 可读的时候，MasterServer 读入内容，如果读入的最后一个字节为 BusyChar，设置 Child 的状态为 Busy；如果为 IdleChar ，设置 Child 的状态为 Idle；如果读入 0 字节，那么表示 Child 已经关闭 ChildPipe ，也就表明 Child 已经异常退出了。
7. ChildServer 被创建出来之后，就在 ListenFd 上 accept ，如果 accept 成功就通过 ChildPipe 发送一个 BusyChar，然后开始处理；处理结束之后，再通过 ChildPipe 发送一个 IdleChar；接着检查 PipeOfDeath 是否有内容，如果读到有内容，那么子进程自行退出；

关于几个主要文件句柄的传递说明：
1. ManagerPipe ：MasterServer 创建，传递给 ProcessManager（通过 Fork）
2. ListenFd ：MasterServer 创建，传递给 ProcessManager（通过 Fork），由 ProcessManager 传递给 ChildServer（通过Fork）
3. PipeOfDeath ：MasterServer 创建，传递给 ProcessManager（通过 Fork），由 ProcessManager 传递给 ChildServer（通过 Fork）,MasterServer 持可写的一端，各个 ChildServer 持可读的一端；PipeOfDeath 在 MasterServer 只有一个句柄；
4. ChildPipe ：MasterServer 创建，传递给 ProcessManager（通过 Send_Fd），由 ProcessManager 传递给 ChildServer（通过 Fork）,ChildPipe 在 MasterServer 有多个，每个 ChildServer 有一个 ChildPipe；