Re: BSD signal not aborting semaphore_wait() in the kernel on an SMP
Re: BSD signal not aborting semaphore_wait() in the kernel on an SMP
- Subject: Re: BSD signal not aborting semaphore_wait() in the kernel on an SMP
- From: Chandra Khan <email@hidden>
- Date: Tue, 19 Oct 2004 22:23:41 -0700
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 (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden