httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Colm MacCarthaigh <c...@stdlib.net>
Subject Re: [PATCH] #39275 MaxClients on startup [Was: Bug in 2.0.56-dev]
Date Sun, 16 Apr 2006 19:09:18 GMT
On Sat, Apr 15, 2006 at 10:20:29AM -0400, Chris Darroch wrote:
>    Re my option C, it also occurs to me that instead of squeezing
> the worker MPM's start and listener threads into extra, internal
> worker_score structures, it might be more appropriate to create a
> new section of the scoreboard with non_worker_score structures.
> These would just have pid, tid, and status fields only.
> 
>    The worker and event MPMs would use these to track their
> non-worker threads; and the parent process for these MPMs could
> monitor them as per option C to decide when the child process's
> workers were ready to be counted.

+1, I think this could be very useful, I came accross the same kind of
problems when looking at handling the odd mod_cgid race conditions when
doing graceful stops, but in the end didn't solve them (we still have
slightly different death semantics between prefork and worker-like MPM's
for cgi termination).

>    Finally, a question without checking the code first ... I notice
> that worker.c has the following, taken from prefork.c:
> 
>     /* fork didn't succeed. Fix the scoreboard or else
>      * it will say SERVER_STARTING forever and ever
>      */
>     ap_update_child_status_from_indexes(slot, 0, SERVER_DEAD, NULL);
> 
> Is that right?  Should it perhaps cycle through and set all
> non-DEAD workers to DEAD?  I'm thinking that in prefork,
> threads_limit is set to 1, so mod_status only checks the first
> thread in a slot, but here it'll check all of them.

I'm not sure what you mean. As in, all potential workers globally? That
child isn't going to have any actual workers, since child_main() never
got run.

-- 
Colm MacCárthaigh                        Public Key: colm+pgp@stdlib.net

Mime
View raw message