Subject: Re: Speeding up fork/wait path
To: None <tech-kern@NetBSD.org>
From: Allen Briggs <briggs@wasabisystems.com>
List: tech-kern
Date: 10/25/2003 17:58:38
On Sat, Oct 25, 2003 at 11:00:44PM +0200, Jaromir Dolecek wrote:
> I'm not sure I completely understand the logic, but I cannot see
> why it would be necessary to run the final child cleanup (work
> done by reaper) from process context. Neither of those two
> routines can block, can it? Theoretically it might be possible
> to do the cleanup directly from within exit2/lwp_exit2, avoiding
> the reaper entirely, right?

I think that the idea is that you might block in a multiprocessor
environment and/or if parts of the process context are swapped out.

One alternative is to make the status code available to the parent
as soon as the process enters SDEAD but that would also entail some
careful use to ensure that the right things happen whenever the
parent does grab the status (i.e., the reaper should still clean
up the process's resources and the process should proceed to SZOMB
state or just go away, depending on whether or not the status has
been grabbed).  The current model is pretty clean.

I have to ask, though, if this would be a real-world gain (given
that you still incur the same context switches)?  I suppose it
would mean that a process waiting for the exit could get the result
a bit sooner and could fire off another process a bit sooner (with
the slight chance that it would fire up with some resource starvation
that would be satisfied by the reaper).

-allen

-- 
 Allen Briggs                     briggs@wasabisystems.com
 Wasabi Systems, Inc.             http://www.wasabisystems.com/