httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Darroch <>
Subject Re: [PATCH] #39275 MaxClients on startup [Was: Bug in 2.0.56-dev]
Date Sat, 15 Apr 2006 14:20:29 GMT
Hi --

> for (i = 0; i < ap_threads_per_child; i++) {
>     if (status != SERVER_GRACEFUL && status != SERVER_DEAD) {
>         ap_update_child_status_from_indexes(slot, i, SERVER_INIT, NULL);
>     }
> }
> ... after make_child() does its check for != GRACEFUL and != DEAD ...

   After heading back to bed I realized this should be, of course,

if (status == SERVER_GRACEFUL || status == SERVER_DEAD)

   Never cut-'n'-paste when you're tired!

   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.

   It would also solve an outstanding problem for me with a
module I maintain that uses its own private threads; there's
nowhere in the scoreboard that I know of where I can register
them.  That might also intersect with this conversation:

   A possible set of calls for managing these might be:

num = ap_register_non_worker_thread(slot, tid, status)
ap_update_non_worker_status_from_indexes(slot, num, status)
ap_unregister_non_worker_thread(slot, num)
ret = ap_get_scoreboard_non_worker(slot, num, &status)

   The child process registers its non-worker threads, making
sure that it registers one of them as STARTING immediately after
ap_reopen_scoreboard() so that it precedes ap_run_child_init().
This will be guaranteed to go into the [slot][0] structure.
It can then set that to READY once it's ready for its workers
to be counted individually.

   Then the parent process can monitor that structure's status
using ap_get_scoreboard_non_worker(), and do the "wait till
all workers are running" thing in p_i_s_m().  Meanwhile
mod_status can call ap_get_scoreboard_non_worker until it
returns an error code and then it'll know it's checked all
the registered non-workers; these can be displayed in the report.

   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.


GPG Key ID: 366A375B
GPG Key Fingerprint: 485E 5041 17E1 E2BB C263  E4DE C8E3 FA36 366A 375B

View raw message