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 | 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.