httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brian Havard" <>
Subject Re: OS/2 Scoreboard changes
Date Wed, 07 Feb 2001 14:53:26 GMT
On Tue, 6 Feb 2001 16:43:01 -0800 (PST), wrote:

>> >I purposefully did not put an apr_os_thread_t into the scoreboard, because
>> >I couldn't see how it was useful to all MPMs.  The thread_num allows MPMs
>> >to associate a single integer with a specific thread id.
>> I need a tid for the same reason prefork needs a pid. If a thread
>> terminates the OS gives us its tid, we need to find which slot that
>> corresponds to somehow.
>But you are running as a single process, right?  Can you use the same
>model that dexter uses.  In dexter, each child process is responsible for
>managing itself.  The scoreboard is really being used as a means for
>communicating information to mod_status.

Well, its the way I was doing it in the scoreboard.h you deleted & had to
get it to build again. I saw no reason to create another per thread array
when we already had the scoreboard but if we want to keep the scoreboard
down to just the info that's interesting to mod_status then I can do just
that. I'd argue though that tid should stay, it's more interesting than pid
in a single procecss multi-thread server.

>My understanding of deferred_die from the Unix MPMs, is that it is a
>simple integer, that tells the thread that it should die immediately, or
>that it should die later.  In the other MPMs, this is done with
>workers_may_exit.  I am wondering if the same model can be used for OS/2.

Not really. workers_may_exit is process global and this works because (I
guess) in the event of a restart in an mpmt mpm, the process dies off & is
replaced. In my spmt, only the threads die off so there needs to be a
defered_die flag for each thread.

>The generation is already in the scoreboard, so I am wondering why we are
>adding it here as well.

But it's in the parent record for which there's only 1 per process, not 1
per thread. I need 1 per thread for the same reason as above.

>For thread_retval, on Unix, I can do a thread_join, which basically waits
>for a thread to exit, and then I can capture the thread's return
>code.  You are basically using the thread_retval field for retrieving the
>threads return value, so does this ability not exist in OS/2?

No, OS/2 threads don't have a return code. For APR threads I had to do
something clever, similar to thread_retval but in the apr_thread_t. 

>> >I am very much against the changes that went into the scoreboard.h file
>> >without a very good argument for why they are needed.
>> And you've yet to come up with an actual reason why they shouldn't.
>They shouldn't, because this is code that is used by every MPM, and we
>have been trying to remove #ifdef's, not add them back in.  I believe
>there are a couple of options for how to do this, and I would like our
>goal to be to remove these OS/2 specific fields.  I am not saying they
>need to be removed today, but I would like that to be our overall goal.
>I believe this is possible, and I will work to make sure it is.

Well, because of the single process nature of the OS/2 MPM, I _can_ do it
another way. Multi-process MPMs don't have that option unless they create
another shared memory area so there still may be cases where being able to
put other info in there is useful. Not something I'm going to lose any
sleep over though.

 |  Brian Havard                 |  "He is not the messiah!                   |
 |  |  He's a very naughty boy!" - Life of Brian |

View raw message