httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Hartill <>
Subject Re: non-forking again (NCSA 1.4 approach)
Date Thu, 16 Mar 1995 20:26:20 GMT

Rob McCool writes,
>  * My setup has all the serialization being performed before a call to
>  * accept, so a child is always ready for a connection.  As soon as
>  * the accept is made, the child sends the parent a non-blocking
>  * message to tell it that the 'accept' is now history, and that the
>  * next child can 'accept' a connection.
> One problem with this setup is that the master process can become a
> bottleneck. In a situation of fast connection turnover, before a
> connection can be accepted, the process which made the accept must
> wake up, and send a message. The master process must then run, and
> send a message. Finally, the next child must run, and accept a
> connection. If you have a lot of running processes, requiring three
> process switches per new connection might become a problem.

This system is only needed on MP machines which have problems with
simultaneous accepts. It has the potential to stay one step ahead of
each connection since a new child is made ready as soon as the 
existing accept has been made. Now if this is on a MP system where
simultaneous accepts aren't allowed, it's sure to be an improvement
over forking. I've no feel for how it would compare with a shared
memory alternative.

> That being said, this method may be better than the simple
> architecture or the fd-write architecture.
>  * (*) is easily switched to multiple processes 'accepting' - with no
>  * need for a parent to act as a serializer - that I guess should be a
>  * system dependent config setting.
>  */
> If you did that, how would that be different from the Netsite mob
> architecture?

I've no idea. I don't know how Netsite works, I tried to look at the
source but it was just all 1s and 0s  ;-)


View raw message