Re: How to kill an IOKit thread?
Re: How to kill an IOKit thread?
- Subject: Re: How to kill an IOKit thread?
- From: Jim Magee <email@hidden>
- Date: Wed, 31 Jul 2002 15:53:39 -0400
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 | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/darwin-kernel
Do not post admin requests to the list. They will be ignored.