You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by rb...@covalent.net on 2001/02/06 18:34:49 UTC
OS/2 Scoreboard changes
The OS/2 scoreboard changes have broken every other platform. I do not
believe we should be re-defining the scoreboard based on platform. If the
MPM needs more information than the scoreboard currently provides, then
the MPM will need to allocate space for that information itself.
The problem that was introduced, is that the scoreboard.h file includes
mpm.h, which includes scoreboard.h. This causes the compile to break.
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.
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.
I am very much against the changes that went into the scoreboard.h file
without a very good argument for why they are needed.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: OS/2 Scoreboard changes
Posted by rb...@covalent.net.
> > The OS/2 scoreboard changes have broken every other platform.
>
> Well, in a way it is only fair, since OS/2 seems to keep getting broken
> by changes on the other platforms.
>
> > The problem that was introduced, is that the scoreboard.h file includes
> > mpm.h, which includes scoreboard.h. This causes the compile to break.
>
> Oh, foo -- this is so easily worked around it is pitiful. Make sure
> both files have the requisite #ifndef AP_foo_H sections.
I probably should have mentioned that they each need types defined in the
other file.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: OS/2 Scoreboard changes
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
rbb@covalent.net wrote:
>
> The OS/2 scoreboard changes have broken every other platform.
Well, in a way it is only fair, since OS/2 seems to keep getting broken
by changes on the other platforms.
> The problem that was introduced, is that the scoreboard.h file includes
> mpm.h, which includes scoreboard.h. This causes the compile to break.
Oh, foo -- this is so easily worked around it is pitiful. Make sure
both files have the requisite #ifndef AP_foo_H sections.
--
#ken P-)}
Ken Coar <http://Golux.Com/coar/>
Apache Software Foundation <http://www.apache.org/>
"Apache Server for Dummies" <http://Apache-Server.Com/>
"Apache Server Unleashed" <http://ApacheUnleashed.Com/>
Re: OS/2 Scoreboard changes
Posted by Greg Stein <gs...@lyra.org>.
On Tue, Feb 06, 2001 at 04:51:08PM -0800, rbb@covalent.net wrote:
>...
> > How about putting a "void *mpm_ctx" into the scoreboard? Would that help?
> > The OS/2 MPM could hang a structure off of that.
>
> That is what I am thinking, but I REALLY want this idea to work for all
> scoreboard's, including shared memory.
Great ideal, but I'd suggest adding the void* for now. For single-process
MPMs, they can begin using it immediately.
When you have a complete solution, then we can migrate there. But if we wait
for the complete thing, and you get occupied with other things, then we
could end up waiting a very long time. And all that MPM-specific stuff will
still be in there.
Do a bit now. Do some more later. Don't wait for the whole bundle. It's
analogous to the "release early, release often" mantra.
> > It won't work if the scoreboard is in shared mem, but it certainly gets us
> > out of the OS/2 specific changes to the scoreboard.
> >
> > For people using the shared memory version of the scoreboard, would it be
> > possible for the MPM to say "add this much space onto the end of the
> > scoreboard entries, so that I can store private stuff in there" ??
>
> You're right where I was last week, when I last thought about this
> problem. The basic problem, is that MM requires additional space
> everytime we call mm_malloc. For example, if we call apr_shm_init(1024),
> and then apr_shm_malloc(1024), in reality MM sets up 1024+sizeof(MM) bytes
> of shared memory and then during the mm_malloc call, it uses
> sizeof(MM) bytes for the MM structure, and 1024 bytes for what we asked
> for.
>
> The problem is then that if we do the following, we don't have enough
> memory:
>
> apr_shm_init(1024);
> apr_shm_malloc(512);
> apr_shm_malloc(512);
>
> Again, the shm_init call added sizeof(MM) to the 1024, but it has no idea
> how many times we are going to malloc out of the shared memory.
Yes, this is problematic, but it doesn't really apply to the scoreboard
problem. We can do an apr_shm_init() for the amount of data we need, then
malloc it all in one fell swoop. The scoreboard's shared mem doesn't need to
support multiple mallocs.
> This is why in the old code, we had a fudge factor, and then we just setup
> two apr_shm_t's. The fudge factor won't work, because we still don't
> really know how many different modules will want to use shared memory.
Each person wanting to use shared memory should create their own
apr_shmem_t. We shouldn't be attempting to create one global one for all
modules, for exactly the reasons you state.
> The solution is probably to really look at MM and determine if we really
> want to use it. I am beginning to believe that we don't. More later if I
> can find the time to really look into this in detail.
I don't see any particular problem with MM. Just how we happen to be using
it for the scoreboard.
Hmm... I'm looking at apr_shmem.h right now. It seems to allow multiple
calls to apr_shm_init().
I don't see what the problem is, then. The scoreboard should set up its own
apr_shm_t when it is created. The MPM should tell the scoreboard how much to
tack onto the end of each entry in the scoreboard. We then have a scoreboard
with its declared per-entry data plus some amount of per-MPM data.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: OS/2 Scoreboard changes
Posted by rb...@covalent.net.
> The problem with MM, or the way we're using it, is that it's really doing
> two jobs.
>
> 1) Providing a portable method (between unix versions anyway) of getting a
> block of shared memory.
> 2) implementing a heap within that shared block.
>
> For things like the scoreboard we only need a single block that can be
> provide by (1) alone but we can't get at it.
>
> I think (2) is overkill for APR & makes porting to non-unix platforms more
> difficult (there's still no Win32 version AFAIK). If we actually need a
> heap implementation it should be at a higher, platform neutral level.
How many +1's can I give at a time?
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: OS/2 Scoreboard changes
Posted by Brian Havard <br...@kheldar.apana.org.au>.
On Tue, 6 Feb 2001 16:51:08 -0800 (PST), rbb@covalent.net wrote:
>> For people using the shared memory version of the scoreboard, would it be
>> possible for the MPM to say "add this much space onto the end of the
>> scoreboard entries, so that I can store private stuff in there" ??
>
>You're right where I was last week, when I last thought about this
>problem. The basic problem, is that MM requires additional space
>everytime we call mm_malloc. For example, if we call apr_shm_init(1024),
>and then apr_shm_malloc(1024), in reality MM sets up 1024+sizeof(MM) bytes
>of shared memory and then during the mm_malloc call, it uses
>sizeof(MM) bytes for the MM structure, and 1024 bytes for what we asked
>for.
>
>The problem is then that if we do the following, we don't have enough
>memory:
>
>apr_shm_init(1024);
>apr_shm_malloc(512);
>apr_shm_malloc(512);
>
>Again, the shm_init call added sizeof(MM) to the 1024, but it has no idea
>how many times we are going to malloc out of the shared memory.
>
>This is why in the old code, we had a fudge factor, and then we just setup
>two apr_shm_t's. The fudge factor won't work, because we still don't
>really know how many different modules will want to use shared memory.
>
>The solution is probably to really look at MM and determine if we really
>want to use it. I am beginning to believe that we don't. More later if I
>can find the time to really look into this in detail.
The problem with MM, or the way we're using it, is that it's really doing
two jobs.
1) Providing a portable method (between unix versions anyway) of getting a
block of shared memory.
2) implementing a heap within that shared block.
For things like the scoreboard we only need a single block that can be
provide by (1) alone but we can't get at it.
I think (2) is overkill for APR & makes porting to non-unix platforms more
difficult (there's still no Win32 version AFAIK). If we actually need a
heap implementation it should be at a higher, platform neutral level.
--
______________________________________________________________________________
| Brian Havard | "He is not the messiah! |
| brianh@kheldar.apana.org.au | He's a very naughty boy!" - Life of Brian |
------------------------------------------------------------------------------
Re: OS/2 Scoreboard changes
Posted by rb...@covalent.net.
> > >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.
>
> How about putting a "void *mpm_ctx" into the scoreboard? Would that help?
> The OS/2 MPM could hang a structure off of that.
That is what I am thinking, but I REALLY want this idea to work for all
scoreboard's, including shared memory.
> It won't work if the scoreboard is in shared mem, but it certainly gets us
> out of the OS/2 specific changes to the scoreboard.
>
> For people using the shared memory version of the scoreboard, would it be
> possible for the MPM to say "add this much space onto the end of the
> scoreboard entries, so that I can store private stuff in there" ??
You're right where I was last week, when I last thought about this
problem. The basic problem, is that MM requires additional space
everytime we call mm_malloc. For example, if we call apr_shm_init(1024),
and then apr_shm_malloc(1024), in reality MM sets up 1024+sizeof(MM) bytes
of shared memory and then during the mm_malloc call, it uses
sizeof(MM) bytes for the MM structure, and 1024 bytes for what we asked
for.
The problem is then that if we do the following, we don't have enough
memory:
apr_shm_init(1024);
apr_shm_malloc(512);
apr_shm_malloc(512);
Again, the shm_init call added sizeof(MM) to the 1024, but it has no idea
how many times we are going to malloc out of the shared memory.
This is why in the old code, we had a fudge factor, and then we just setup
two apr_shm_t's. The fudge factor won't work, because we still don't
really know how many different modules will want to use shared memory.
The solution is probably to really look at MM and determine if we really
want to use it. I am beginning to believe that we don't. More later if I
can find the time to really look into this in detail.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: OS/2 Scoreboard changes
Posted by Greg Stein <gs...@lyra.org>.
On Wed, Feb 07, 2001 at 10:57:54AM +1000, Brian Havard wrote:
> On Tue, 6 Feb 2001 09:34:49 -0800 (PST), rbb@covalent.net wrote:
>...
> >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.
How about putting a "void *mpm_ctx" into the scoreboard? Would that help?
The OS/2 MPM could hang a structure off of that.
It won't work if the scoreboard is in shared mem, but it certainly gets us
out of the OS/2 specific changes to the scoreboard.
For people using the shared memory version of the scoreboard, would it be
possible for the MPM to say "add this much space onto the end of the
scoreboard entries, so that I can store private stuff in there" ??
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: OS/2 Scoreboard changes
Posted by rb...@covalent.net.
> When/if we do this, can we try to keep the amount of memory used under
> control? (so that folks who aren't using modules which want to add
> arbitrary data aren't paying a huge penalty in terms of memory used for
> the scoreboard.)
This isn't up to us to do. If a module wants to add an arbitrary amount
of data to the scoreboard, the programmer needs to pay attention to
this. I don't believe we want to try to keep people from hanging
themselves.
> I'm mentioning this because I ran into an out-of-memory situation on an
> OS with constrained virtual memory when I was trying to run 2.0 last
> year with thousands of threads. It looked like there were a couple of
> fudge factors involved in calculating the size of the scoreboard, one of
> which multiplied the previous size by 10 for no obvious reason! I
> believe it was in the pthread mpm, because that's the threaded mpm I use
> most often. This wasn't in the 1.3 scoreboard. Maybe the (size * 10)
> stuff was an early attempt to make the scoreboard bigger to allow for
> arbitrary data.
I do not remember ever multiplying by 10, and we have never tried to allow
modules to add arbitrary data to the actual scoreboard before. The
closest we have come is to give modules a shared memory table that they
can use. This is completely different than what we are talking about now.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: OS/2 Scoreboard changes
Posted by Greg Ames <gr...@raleigh.ibm.com>.
rbb@covalent.net wrote:
>
> > Let me figure out how to get arbitrary modules to add data to the
>
> s/Let me/Let's/
>
> > 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.
>
When/if we do this, can we try to keep the amount of memory used under
control? (so that folks who aren't using modules which want to add
arbitrary data aren't paying a huge penalty in terms of memory used for
the scoreboard.)
I'm mentioning this because I ran into an out-of-memory situation on an
OS with constrained virtual memory when I was trying to run 2.0 last
year with thousands of threads. It looked like there were a couple of
fudge factors involved in calculating the size of the scoreboard, one of
which multiplied the previous size by 10 for no obvious reason! I
believe it was in the pthread mpm, because that's the threaded mpm I use
most often. This wasn't in the 1.3 scoreboard. Maybe the (size * 10)
stuff was an early attempt to make the scoreboard bigger to allow for
arbitrary data.
Thanks,
Greg
Re: OS/2 Scoreboard changes
Posted by rb...@covalent.net.
> Let me figure out how to get arbitrary modules to add data to the
s/Let me/Let's/
> 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
-------------------------------------------------------------------------------
Re: OS/2 Scoreboard changes
Posted by rb...@covalent.net.
> >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
-------------------------------------------------------------------------------
Re: OS/2 Scoreboard changes
Posted by Brian Havard <br...@kheldar.apana.org.au>.
On Tue, 6 Feb 2001 16:43:01 -0800 (PST), rbb@covalent.net 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! |
| brianh@kheldar.apana.org.au | He's a very naughty boy!" - Life of Brian |
------------------------------------------------------------------------------
Re: OS/2 Scoreboard changes
Posted by rb...@covalent.net.
> 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
-------------------------------------------------------------------------------
Re: OS/2 Scoreboard changes
Posted by Brian Havard <br...@kheldar.apana.org.au>.
On Tue, 6 Feb 2001 09:34:49 -0800 (PST), rbb@covalent.net wrote:
>The OS/2 scoreboard changes have broken every other platform. I do not
>believe we should be re-defining the scoreboard based on platform. If the
>MPM needs more information than the scoreboard currently provides, then
>the MPM will need to allocate space for that information itself.
>
>The problem that was introduced, is that the scoreboard.h file includes
>mpm.h, which includes scoreboard.h. This causes the compile to break.
Ok, I didn't spot that, obviously it worked for me. I've just commited a
fix (I hope).
>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.
>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.
>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.
--
______________________________________________________________________________
| Brian Havard | "He is not the messiah! |
| brianh@kheldar.apana.org.au | He's a very naughty boy!" - Life of Brian |
------------------------------------------------------------------------------