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: Jim Magee <email@hidden>
- Date: Wed, 20 Oct 2004 12:21:05 -0400
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.
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...
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 (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden