Re: Waking a socket call from an alternate thread.
Re: Waking a socket call from an alternate thread.
- Subject: Re: Waking a socket call from an alternate thread.
- From: Jim Magee <email@hidden>
- Date: Mon, 28 Jul 2003 15:16:11 -0400
On Monday, July 28, 2003, at 3:39 AM, Wally Crooze wrote:
Our filesystem requires a mechanism to wake up these calls and give an
indication that the thread was interrupted/awoken. This indicator
could be through an error or alternatively handle by our own code. But
the mechanism to wake up the calls is MacOSX specific and even if we
play with internal structures to mimic this... the outcome will be an
OS version specific hack that can only be expected to handle the
*obvious* conditions.
Could somebody give me the supported mechanisms to wakeup/interrupt
socket calls which will support all (hopefully) the cases that they
could sleep. This is very important due to our filesystem being in a
clustered network that must handle failover and redistribution.
I assume you are trying to do this all from within the kernel? In that
case, there is no SUPPORTED mechanisms to do this. At user-space, you
could use pthread_kill() to send signals to your "worker" thread. You
would have to check for EINTR and do the appropriate thing. But there
is no pthread library, and therefore no pthread_kill() API. within the
kernel.
Within the kernel, the mechanism underlying all of these interruption
mechanisms are represented by the Mach SPIs thread_abort() and
thread_abort_safely(). They both interrupt a thread out of
interruptible kernel operations. The former may leave the current
operation in a non-restartable state. It is usually restricted to "kill
-9" type operations where you don't care about restarting the current
operation.The latter will only interrupt threads that can safely
restart their current operations after handling the interruption.
However, there is a "trick" to using these thread_abort() mechanisms
within the kernel. Usually, the code that implements the
return-to-user-space handling resets these conditions. For pure kernel
threads, that path is not executed (and there is no published API to
simulate it either). You could, however, work with a
"borrowed/captured" user thread and return it user-space when EINTR is
detected (to clear the interrupted condition).
But as I said, use of these thread_abort() SPIs should be considered
"at your own risk." No guarantees are made about their correctness (or
even existence) from release to release. But enough code uses them
(including Java runtime, Carbon thread manager, and BSD signals) at
their core, that they are not likely to become invalid anytime soon.
--Jim
_______________________________________________
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.