Re: waiting queue
Re: waiting queue
- Subject: Re: waiting queue
- From: Jim Magee <email@hidden>
- Date: Fri, 8 Dec 2006 11:12:22 -0800
Just a clarification on the subtleties of the THREAD_XXX interruptible
flags.
On Dec 5, 2006, at 11:11 AM, Michael Smith wrote:
I have one question left where the documentation does not tell me
the whole story:
#define THREAD_UNINT 0 /* not interruptible
The sleep is guaranteed to return, and only when someone explicitly
wakes it up. It will return THREAD_AWAKENED.
Absolutely correct.
#define THREAD_INTERRUPTIBLE 1 /* may not be restartable */
The sleep is guaranteed to return, but may do so for various reasons
(e.g. a signal has been sent to the thread). It will return
THREAD_AWAKENED if it was woken up explicitly, and
THREAD_INTERRUPTED if it was woken for some other reason. If it
returns THREAD_RESTART (or anything else) you should restart the
sleep.
Actually, the distinction is more subtle than that. You use this
state when you want the wait to return only when someone explicitly
wakes you up or the current process/thread is being killed. The only
signal that interrupts this state is a "kill -9".
Providing this value means that your operation may not be cleanly
restartable for the current process/thread (you might lose the result
of the operation as detectable only from the current client
connection), but since it is exiting anyway, you're willing to cut the
operation short in that case. Of course, the "system as a whole" has
to be able to cleanly deal with/recover from this interruption (the
device as a whole must still be a consistent/recoverable state after
the interruption).
This state is sticky. Once a thread is marked for termination, each
and every interruptible wait will return immediately until the thread
actually exits.
#define THREAD_ABORTSAFE 2 /* abortable safely */
The sleep is not guaranteed to return. This is a promise on your
part that the thread can be aborted (destroyed) while asleep without
affecting your code. Generally in the driver environment this is OK
to use while you hold no locks or resources (e.g. whilst waiting to
get into your driver), but otherwise you should avoid it. You are
not notified when the thread is aborted; it just never comes back.
All waits return (unless you directed them to a continuation routine -
but in that case the continuation routine will always be called for
each wait). Threads never just disappear out from under you.
What this value means is that you are willing to interrupt the current
wait (and proceed to unwind back to the system call/trap) in the face
of "any" user signal. Many of those syscalls/traps may try to restart
the operation after the signal is handled. Your driver must be able
to deal with that if you use this value during your wait. But you
must provide this value for any unbounded wait - lest you pend such
signals forever.
The Mach operation that is used to poke a thread in the case of such
non-fatal signals is a thread_abort_safely() call (only abort the
current wait if the thread is waiting "safely"). Hence the origin of
the flag's name.
This state is not guaranteed to be sticky. Once one wait detects it,
the code in its return path to the user must be able to unwind and
avoid subsequent unbounded wait calls. So, in order to unwind
cleanly, you likely have to return an error code to you caller that
will allow them to understand you are interrupting the current call,
and they do it to their caller, etc..., etc..., etc...
--Jim
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden