On Wednesday, July 31, 2002, at 03:30 PM, Jim Magee wrote: Regardless of that little confusion, it is always best to let the thread terminate itself. Simply wake it up from that block such that it notices it should kill itself. Then just have it call thread_terminate(current_act()). If it truly is a kernel thread, it will not return from this call. However, if it really is user-level thread, the thread will only be marked for termination, and will not terminate until it unwinds out of its current system call. It will stop just short of returning to user-space and then will finish the job of terminating itself. And, as I should have checked before posting this, IOExitThread() encompasses exactly this sentiment. On a more general note, there is no "terminate that other thread" primitive in all the kernel which will work on a kernel thread. The thread_terminate() primitive will fail when called on a kernel thread activation other than the current one. It's that highly discouraged a practice. ;-) Is the problem that you don't know how to wake it from the blocking call it made? Which call is it? Maybe we can make suggestions on how to "roust" your thread such that it notices it should come back and terminate itself(). --Jim PS: An important note: Even though IOCreateThread returns a thread [shuttle] pointer (something it really shouldn't really do for other reasons), it does not return a thread [shuttle] reference. Therefore, the thread [shuttle] pointer is only valid as long as you are positive that it has not already been terminated. PPS: The reason I keep putting "[shuttle]" in these comments is that within the kernel, a thread really consists of two parts, an activation (which represents the state of the thread), and a shuttle (which is the scheduled entity). The activation is what people traditionally call a "thread," and is the handle by which they should be manipulated. The shuttle is an internal construct, separated from the activation itself, to allow for a more efficient implementation of priority inheritance mechanism (known as thread migration). Our goal is to make it so that no entity outside of Mach itself should have direct access to the shuttle. _______________________________________________ darwin-kernel mailing list | darwin-kernel@lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.