site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com Domainkey-signature: a=rsa-sha1; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=FEgqlQlPPWNQWfJ/PM6M99Qy7lmn7Mj+59jV5hotftJOB+KYeVhMyzi3j2aPxnERmUJ7otfUS20HSfcgQHK/yHcV24cELnHq5EhH5LyU6/paEoWfIug/7Nh5Wig0X8eXC2oU5QQbr8iuP113hVu86s9yYSeC2z6w4nT1iKkw4tM Thanks for the response. Please see my comments below. On Tue, 19 Oct 2004 18:24:25 -0400, Jim Magee wrote:

Do you have more than one thread in the parent process? The SIGCHLD is only delivered to one thread, not all of them. So other threads waiting down in the ioctl() would be unaffected.

Both the parent and the child processes are single threaded.

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.

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 } } The parent's SIGCHLD handler actually runs when the child gets a signal. However, I find that the parent is indefinitely stuck in the semaphore_wait(), ie, child_was_signaled() doesn't run. 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...

Oh, and some particulars about which version of the OS/kernel you are running would be helpful. Some of this stuff behaves slightly differently between releases.

It's xnu 517.7.21, darwin kernel 7.5.0. Just curious, what behavior is different? Thanks for your help, Chandra _______________________________________________ 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