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.
><[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 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
