On Wed, Jan 10, 2001 at 05:58:42PM -0800, Jason R Thorpe wrote:
> Yes, that could be done.  However, that means that the unsuspecting
> process can be charged for time accumulated by reaping the process,
> not necessarily something you want (or, it could block, and if it's
> a very high priority process, you don't want that, either).

sure, but that points to an underlying problem with the 
interrupt-driven accounting mechanism that the kernel currently
uses.  there are a lot of unsuspecting processes out there.  (e.g.
how do you account for interrupt-level network processing?)

in the mean time, the rub is that the reaper inserts an extra two 
un-necessary hardware context switches at process exit time.


> Another nice thing about the reaper is that it can be made into a
> very low priority thread, effectively creating a pool of contexts
> that can be re-used at thread creation time ... this is something
> that Solaris does, although our reaper does not (yet).

ok, but does having that pool of contexts for reuse require 
having a reaper process, or is having a reaper process an 
orthogonal issue?


chuck