Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!pt.cs.cmu.edu!andrew.cmu.edu!+ From: Richard.Draves@CS.CMU.EDU Newsgroups: comp.os.mach Subject: Re: notification of thread death Message-ID: Date: 16 Feb 90 05:16:37 GMT References: <371@kgw2.bwi.WEC.COM> <8ZqaNoK00hYPEpsEdz@cs.cmu.edu>, <1126@mtxinu.UUCP> Distribution: usa Organization: Carnegie Mellon, Pittsburgh, PA Lines: 39 In-Reply-To: <1126@mtxinu.UUCP> 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