tech-userlevel archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: inetd tests failing



>>> Here's what Christos had to say about it: "Means that once a
>>> preforked child is done you can either wait(2) for it and end it or
>>> you can put it back of the list of available processes so that it
>>> can handle more requests."

This sounds nonsensical to me.

>> Yeah, it does seem confusing to actually implement.

It seems to me confusing to even contemplate.

> It makes a lot of sense if the daemon is slow to start up and does
> not keep state between requests - simply putting the daemon instance
> back on the prefork queue saves time and load.

This doesn't even make sense unless (a) you keep a separate list for
each service, (b) the daemon is expecting this (and thus signals its
doneness by some means other than exiting), (c) you invent some
interface for passing each new connection to an existing daemon
process, and (d) you make all the daemons - including admin-provided
legacy daemons - handle it.

> The apache http daemon has been doing this for a long time...

Apache's children - those children, at least - don't exec.  inetd
children usually do, and the resulting processes have, in general, no
way to be told "now go exec this other process instead, with this fd",
so it doesn't make sense to me to put preforked children which are
"done" back into a pool.

"...you can either wait(2) for it and end it or you can put it back in
the list of available processes...".  This makes no sense to me; you
can't wait(2) for it until it exits [or stops - see below], and if it
does that there is no more process to be put back anywhere - unless
someone has added a way to resurrect a zombie with an exec of a
potentially different image.

Unless you are thinking the forked children should stop themselves
instead of exiting and then *somehow* learn the new connection and exec
path for the next thing inetd wants to use them for?  That's a lot more
moving parts and a lot more fragility than just letting the existing
child exit and forking a new one.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B


Home | Main Index | Thread Index | Old Index