On Fri, 04 Mar 2005 14:26:36 -0600, William A. Rowe, Jr.
<[EMAIL PROTECTED]> 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,
pre
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 stra
On Fri, 04 Mar 2005 11:15:25 -0600, William A. Rowe, Jr.
<[EMAIL PROTECTED]> 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
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
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
