Re: non-forking again (NCSA 1.4 approach)

[Rob Hartill <ha...@ooo.lanl.gov>]

Brandon Long wrote,

> One other item of note: we don't have multiple children waiting on
> accept, though its been batted around.  I had no idea what it would
> do.  Currently, we use file descriptor passing to pass the accepted 
> socket from the 'root' process to a 'child.'  

The method I prototyped the other day has one child process
doing an accept(*) - so as soon as the connection is made, the
child is ready to go. If the parent does the accept, then it
has to wait on accept, then tell a child (does it have to use
an algorithm here to pick one?) about the connection - this
must surely impact on performance.

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.

(*) 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.


rob

Re: non-forking again (NCSA 1.4 approach)

[Rob McCool <ro...@netscape.com>]

/*
 * "Re: non-forking again  (NCSA 1.4 approach)" by Rob Hartill
 *    written Thu, 16 Mar 95 14:16:02 MST
 * 
 * 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.

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?

--Rob