Mailing-List: contact new-httpd-help@apache.org; run by ezmlm
Precedence: bulk
Reply-To: new-httpd@apache.org
Date: Tue, 6 Feb 2001 16:43:01 -0800 (PST)
From: rbb@covalent.net
To: "new-httpd@apache.org" <new-httpd@apache.org>,
    Brian Havard <brianh@kheldar.apana.org.au>
Subject: Re: OS/2 Scoreboard changes
In-Reply-To: <200102062357.KAA14397@silk.apana.org.au>
Message-ID: <Pine.LNX.4.21.0102061631220.30609-100000@koj>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII


> Ok, I didn't spot that, obviously it worked for me. I've just commited a
> fix (I hope).

Cool, thanks.

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

Also, if I could figure out how to let individual modules add arbitrary
information into the scoreboard, so that the OS/2 MPM can just add it's
own structure, could we move this stuff then?  I have been looking at
doing that soon, but I haven't really had a chance yet.  My goal for the
scoreboard, is to keep the scoreboard as clean as possible, so that it
primarily has the information required by mod_status, and everything else
is managed by the module that needs it.

> >The other OS/2 specific changes that were introduced into the scoreboard
> >also scare me.  Why does OS/2 need to put the deferred_die, thread_retval,
> >and generation into the scoreboard.  The deferred_die is specific to the
> >MPM itself, and should be kept away from all other modules.  The same goes
> >for the thread_retval and generation.  Those fields need to be removed
> >from the scoreboard.
> 
> And put where? Are you saying I should create yet another global structure
> to store them? They're there so that the parent thread can communicate with
> the child threads.

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.

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

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?

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

Ryan

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