Re: fork() loses when thread self port's refcount is max'ed out

[Marcus Brinkmann]

On Sat, Oct 12, 2002 at 10:37:52PM -0400, Roland McGrath wrote:
> Generally speaking, leaking send rights should be considered like leaking
> memory and programs that leak any send rights are buggy.  This goes for the
> thread and task send rights just like any other.  The mach_task_self macro
> uses a variable containing a right gotten once at startup, and ordinarily
> no urefs are added.  Calling mach_thread_self is usually pretty rare.
> cthreads and libc always look at their stack data structures to find the
> right they saved at thread creation, and don't add urefs.
> 
> For your example calling mach_thread_self 64k times, I think if you do that
> and then random things like fork fail coherently with an error code, you
> are just getting what you asked for.

I don't think this is very convincing, but I am just willing to accept this
if it is properly documented, too.

I mean, from what you say we have to derive the following rules:

* You can call mach_task_self() anytime you like.  Never deallocate it.
* You should never call mach_thread_self().  If you need to call it, don't
  call it a number of times linear to the running time of the program.  If you
  follow that rule, you could even get away with deallocating the port, but if
  you follow that rule you don't need to deallocate it, so you shouldn't.
* The same rules as for mach_thread_self() should be followed for
  mach_host_self().

I think this is kind of awkward.  For the future (L4, or even in Mach), we
should consider an internal flag that is set when the overflow condition is
triggered, so that we can prevent complete deallocating of the send right. 
Then the rules become simpler because it is then safe to deallocate the
thread/host send right reference.

Thanks,
Marcus

-- 
`Rhubarb is no Egyptian god.' GNU      http://www.gnu.org    marcus@gnu.org
Marcus Brinkmann              The Hurd http://www.gnu.org/software/hurd/
Marcus.Brinkmann@ruhr-uni-bochum.de
http://www.marcus-brinkmann.de/