httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: OS/2 Scoreboard changes
Date Wed, 07 Feb 2001 14:27:46 GMT

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

Ahhhhh, I got you, thanks.

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

Makes sense.

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

Ok.  I little annoying, but that's life.

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

Let me figure out how to get arbitrary modules to add data to the
scoreboard, and let's attack this again at that time.  Is that
reasonable?  I don't want to rip anything out that is required, but I want
to keep the #ifdefs to a minimum, so that the code is less congested.  I
believe that by moving this stuff into an MPM specific region of the
scoreboard, we can satisfy both goals.


Ryan Bloom               
406 29th St.
San Francisco, CA 94131

View raw message