You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Jeff Trawick <tr...@gmail.com> on 2005/03/04 11:20:36 UTC
relatively minor 2.1 API change
worker_score in scoreboard.h needs a pid_t field. The worker MPM (and
probably some other Unix threaded MPMs) has a perhaps-unexpected way
of handling child processes which are terminating gracefully -- it
allows new child processes to take over the process_score structure
and the worker_score structure for all threads except for the ones
handling long-running requests in the old child process.
Because there is not a pid_t field in worker_score, mod_status can't
display the id of the process handling that particular request, which
makes it difficult to determine which requests are being handled by
some httpd process which is trying to terminate.
So step 1 is add the pid_t field and bump MMN.
Step 2 is to teach worker MPM to maintain it properly.
Step 3 is to teach mod_status to check that field for non-zero (i.e.,
implemented by MPM) and , if set, use that instead of the
process_score field.
Any concerns?
Re: relatively minor 2.1 API change
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Mar 4, 2005, at 5:20 AM, Jeff Trawick wrote:
> worker_score in scoreboard.h needs a pid_t field. The worker MPM (and
> probably some other Unix threaded MPMs) has a perhaps-unexpected way
> of handling child processes which are terminating gracefully -- it
> allows new child processes to take over the process_score structure
> and the worker_score structure for all threads except for the ones
> handling long-running requests in the old child process.
>
> Because there is not a pid_t field in worker_score, mod_status can't
> display the id of the process handling that particular request, which
> makes it difficult to determine which requests are being handled by
> some httpd process which is trying to terminate.
>
> So step 1 is add the pid_t field and bump MMN.
> Step 2 is to teach worker MPM to maintain it properly.
> Step 3 is to teach mod_status to check that field for non-zero (i.e.,
> implemented by MPM) and , if set, use that instead of the
> process_score field.
>
+1
Re: relatively minor 2.1 API change
Posted by Jeff Trawick <tr...@gmail.com>.
On Fri, 04 Mar 2005 14:26:36 -0600, William A. Rowe, Jr.
<wr...@rowe-clan.net> wrote:
> That scares me from a win32 perspective; fyi. apr_os_thread_t
> is a HANDLE, an object meaningless outside the scope of a specific
> process.
looks like OS/2, BEOS, and NetWare MPMs use that thread id field,
presumably for their own management purposes; I don't see any other
code using it
Re: relatively minor 2.1 API change
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
That scares me from a win32 perspective; fyi. apr_os_thread_t
is a HANDLE, an object meaningless outside the scope of a specific
process. If Win32 goes 2x ++ processes, this data doesn't help.
But obviously, apr_thread_t is a complex structure, so it's not
the right choice either. Perhaps a straightforward int thread
and process id? Do these actually get used (as opposed to displayed
or compared)?
Bill
At 02:00 PM 3/4/2005, Jeff Trawick wrote:
>On Fri, 04 Mar 2005 11:15:25 -0600, William A. Rowe, Jr.
><wr...@rowe-clan.net> wrote:
>> At 04:20 AM 3/4/2005, Jeff Trawick wrote:
>> >worker_score in scoreboard.h needs a pid_t field.
>>
>> As long as you store the pid:tid atom, I'm +1. Quite right,
>> those tid's can become somewhat meaningless out of context.
>
>already has tid
>
>struct worker_score {
> int thread_num;
>#if APR_HAS_THREADS
> apr_os_thread_t tid;
>#endif
>
>I'll do something like
>
>struct worker_score {
> int thread_num;
> pid_t pid; /* With some MPMs (e.g., worker) this can occasionally be
> * different than the pid_t stored in the
>process_score.
> */
>#if APR_HAS_THREADS
> apr_os_thread_t tid;
>#endif
Re: relatively minor 2.1 API change
Posted by Jeff Trawick <tr...@gmail.com>.
On Fri, 04 Mar 2005 11:15:25 -0600, William A. Rowe, Jr.
<wr...@rowe-clan.net> wrote:
> At 04:20 AM 3/4/2005, Jeff Trawick wrote:
> >worker_score in scoreboard.h needs a pid_t field.
>
> As long as you store the pid:tid atom, I'm +1. Quite right,
> those tid's can become somewhat meaningless out of context.
already has tid
struct worker_score {
int thread_num;
#if APR_HAS_THREADS
apr_os_thread_t tid;
#endif
I'll do something like
struct worker_score {
int thread_num;
pid_t pid; /* With some MPMs (e.g., worker) this can occasionally be
* different than the pid_t stored in the
process_score.
*/
#if APR_HAS_THREADS
apr_os_thread_t tid;
#endif
Re: relatively minor 2.1 API change
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 04:20 AM 3/4/2005, Jeff Trawick wrote:
>worker_score in scoreboard.h needs a pid_t field.
As long as you store the pid:tid atom, I'm +1. Quite right,
those tid's can become somewhat meaningless out of context.
Bill