erich@kgw2.bwi.WEC.COM (Eric Hammond) (02/14/90)
In writing multi-threaded applications in Mach on the NeXT
it would be useful to get notification when one of the threads
dies. Does anybody know how to obtain this information?
I am using the Mach cthreads package with threads that have been
chtread_detach()ed. (I do not want to have to cthread_join().)
I would like to receive notification of the death of the thread's
kernel port on the task notify port. However, all my tests show
that when a thread dies no notification is send to the task
notify port of the task in which the thread was running. In fact,
when a thread dies by means of thread_exit() or simply a return
from the thread's top level function no notification is sent to
any other tasks which have send rights to that thread's kernel
port. (Incidentally, this might explain why gdb still thinks
that the thread is alive (using 'tl') when a thread exits in this
way.)
I have been able to get a notify message if I terminate
a thread using the following function call:
thread_terminate(cthread_thread(cthread_self()));
However, the notification message is only sent to notify ports
of other tasks which have send rights to the thread's kernel port.
I also do not want to have to poll using
task_threads(task_self(), ...)
Any information or suggestions by email would be appreciated. I
will post a summary if/when significant facts are revealed to me.
--
Eric Hammond
erich@kgw2.bwi.wec.comRichard.Draves@CS.CMU.EDU (02/15/90)
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. 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. In any case, I don't think it is a good idea to kill a thread that the cthreads library thinks it is using. Perhaps you could just have your cthread send its own notification messages before it exits? Rich
frk@mtxinu.COM (Frank Korzeniewski) (02/16/90)
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)
Richard.Draves@CS.CMU.EDU (02/16/90)
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
frk@mtxinu.COM (Frank Korzeniewski) (02/17/90)
In article <AZqsmpm00hYPAyhWFT@cs.cmu.edu> Richard.Draves@CS.CMU.EDU writes: >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? > Ahhhh. Excuse me. I was confusing the unix process model with mach task/threads. As you point out resources are owned by tasks not by threads. The rest of my comments are based on this misunderstanding and are even less relavent. Now that I think about it a little more, I realize that if threads did own resources, there would be no difference between threads and processes. This would mean that there are problems for which threads are appropriate, and those for which tasks (processes) are appropriate. This does point out to me that threads are not a replacement for processes, as I had assumed. Sorry that I may have confused the issue for others. > >Rich Frank