🚀 go-pugleaf

Excerpts from netnews.comp.os.mach: 15-Feb-90 Re: notification of thread
.. Frank Korzeniewski@mtxin (2176)

> 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.


Threads don't have receive rights.  Port rights are held by tasks.  What
do you mean by owner/backup thread?  What ports are you worrying about
here?

> 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.

Again, what other ports are you worrying about?

> >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.  (:-)

Do you think it is a good idea to deallocate stdio buffers out from
underneath stdio?

> What you are suggesting here is the abandonment of general purpose
> routine libraries.  This cannot really be considered a GOOD THING,
> can it? 

I don't understand this comment.  My understanding of Eric Hammond's
question is that he wants to find out when a cthread exits, without
using cthread_join(), which is the method supplied by the cthread
library.  He was hoping to use lower level Mach primitives to do this,
assuming that when a cthread exits the underlying Mach thread exits.

Rich