On Wed, 17 Apr 2002, Greg Ames wrote:
> Why do you think it's risky? Worker _might_ be able to service multiple > sockets after a single poll, but it would break prefork for sure. Hmm.. imagine we have Apache with two listening sockets, one #80, very busy with handling usual stuff, and #1080, hadling any weird protocol supported by one of installed modules. Now imagine that a single call to poll reports both of them ready to accept a connection. Apache takes #80 and services it. The second socket (#1080) remains untouched (according to the 'worker' code). Then there come more requests on #80, but #1080 still waits for servicing. Will subsequent poll calls ever notice #1080 again? I mean, before any other connection to #1080 appears? Isn't it that poll notices each event (like a need for accept) only once per socket? And that _all_ reported events have to be handled before the next poll? I am not sure how it works in case of prefork (many descriptors representing the same socket in different processes), but for threaded worker it seems bad. > Let's say the first ready listening socket has a connection that represents > a request to download a CD, and the second has a request for some little > .gif. I see what you mean, but the problem is not serializing connection servicing inside a single worker thread or prefork process (it would be obviously wrong) - it is dealing with many listening sockets, and polling on them. Regards, -- +------------------------ ---- -- -- - - - : Michal Szymaniak | mailto:[EMAIL PROTECTED] .
