Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!cs.utexas.edu!uunet!mtxinu!frk
From: frk@mtxinu.COM (Frank Korzeniewski)
Newsgroups: comp.os.mach
Subject: Re: notification of thread death
Message-ID: <1126@mtxinu.UUCP>
Date: 15 Feb 90 19:19:26 GMT
References: <371@kgw2.bwi.WEC.COM> <8ZqaNoK00hYPEpsEdz@cs.cmu.edu>
Reply-To: frk@mtxinu.UUCP (Frank Korzeniewski)
Distribution: usa
Organization: mt Xinu, Berkeley
Lines: 46

In article <8ZqaNoK00hYPEpsEdz@cs.cmu.edu> Richard.Draves@CS.CMU.EDU writes:
>You are seeing two different problems.
>
>First, when a cthread exits, the underlying Mach thread is not
>terminated.  It is left lying around, and will be reused for a new
>cthread.  Because the underlying Mach thread isn't killed, the thread's
>kernel port isn't deallocated, and you don't see notification messages.
>

Fine, but what about other ports that the thread had recieve rights for.
Don't these ports give the rights back to the owner/backup thread?
If not, this seems to be a lack of appropriate cleanup by cthreads/mach.

>Second, when a Mach thread is terminated, there is a special hack to
>keep the task it is in from getting a notification about the death of
>the thread's kernel port.  Other tasks that have send rights for the
>port do get notification messages, as expected.  This speeds up task
>termination, because it saves generating a bunch of notification
>messages (that will never get received) for all the threads.  But it is
>a hack, and I can't defend it very enthusiastically.

Again, special caseing the kernel port is ok, *IF* you correctly clean
up other ports that have been created.  Leaving around these other
ports would seem to eventually result in resource exhaustion.

>In any case, I don't think it is a good idea to kill a thread that the
>cthreads library thinks it is using.

Other than efficiency, I see no justification for this statement. As
long as the os cleans up appropriatly, there should be no problem.
After all, that is what an os is for.  (:-)

>Perhaps you could just have your cthread send its own notification
>messages before it exits?
>
>Rich

What you are suggesting here is the abandonment of general purpose
routine libraries.  This cannot really be considered a GOOD THING,
can it?  Please don't say that it is bad form to just exit on an error.
It can be very difficult for an application to track all system
resources that are being used, and then free them at termination
to avoid possible later deadlock or other failures.  Sending
your own notification is just one example of this.

Frank Korzeniewski       (frk@mtxinu.com)