site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com Absolutely. This explanation here had escaped my mind when I made the initial post. My post was therefore inconsistent and bogus. To illustrate my setup, here's the pseudocode: Parent: sigaction(SIGCHLD, ...) while(1) { ioctl(mydev, BLOCKING_RECEIVE, &blob); if(blob.msg == PARENT_SIGNALED) { // was interrupted because child got a signal child_was_signaled(); } else { // we were woken up by the child process with interesting info // ...work on blob } } ...[snip]... I erroneously concluded that the parent was actually blocked in the semaphore_wait() and wasn't woken up. The real reason, upon further reflection, is the classic "missed wakeup" scenario: the signal came and went before the parent process went to sleep unconditionally. I'm thinking of reworking this to handle the real cause of the child's signal in kernelspace. That would do away with the asynchronous signal. I still need to handle child death avoiding the same race condition. I wonder how one gets notification, in the kernel, of child death... On Oct 20, 2004, at 1:23 AM, Chandra Khan wrote: On Tue, 19 Oct 2004 18:24:25 -0400, Jim Magee wrote: In order to run the signal handler at user space, the thread that ran it MUST first wind its way out of its current system call (and then we run the signal handler instead of returning immediately from the system call). If you are seeing the signal handler run, that thread DID wind out of its current system call. And if the system call in question has the thread blocked in semaphore_wait(), it must have been interrupted out of that wait. You don't - at least not directly. But you shouldn't have to. Your driver should only be involved in death detection to the point at which it directly affects your protocol. For instance: Your driver should be able to detect the last close() that happens in the child side of the device pair - indicating that they are not going to participating in your device protocol any more. It can then wake up and/or return an error to the arriving parent thread's ioctl() call. Otherwise, if you are looking for specific process termination, your device is too intimate with the operation of the child. Maybe it may have to fork() for other reasons of its own leaving the grandchild to do the real work. It's OK for the parent process to have intimate knowledge of how the child behaves, but not the device driver. --Jim _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... This email sent to site_archiver@lists.apple.com