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: Wally Crooze <email@hidden>
- Date: Tue, 05 Aug 2003 15:11:16 +1000
Jim Magee wrote:
On Monday, July 28, 2003, at 3:39 AM, Wally Crooze wrote:
Could somebody give me the supported mechanisms to wakeup/interrupt
socket calls which will support all (hopefully) the cases that they
could sleep.
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.
I've been doing a bit of playing with thread_abort_safely() to wake up
from tsleep() and semaphore_wait(). semaphore_wait() returns a
THREAD_ABORT result in the case of the thread_abort, but in the case of
tsleep() no error is returned... it just wakes up.
Since the tsleep() doesn't return an error how does the socket code know
that it was interrupted /aborted? I would have expected EINTR to be
returned from tsleep()...
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).
I don't understand this "trick".
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.
Are there plans to support thread "interruption" in the future? This is
a real hinderance... and from what I've seen it appears that all threads
sleep on a wait_queue which is easily accessible from within the kernel
(not kext).
--
Wally Crooze
+-------------------------------------------------------+
| ,-_|\ Wally Crooze <email@hidden> |
| / \ |
| \_,-._/ |
| v |
+-------------------------------------------------------+
_______________________________________________
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.