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 <wallycrooze@pobox.com> | | / \ | | \_,-._/ | | v | +-------------------------------------------------------+ _______________________________________________ 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.