httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From r..@covalent.net
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

_______________________________________________________________________________
Ryan Bloom                        	rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------


Mime
View raw message