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: Tue, 19 Oct 2004 18:24:25 -0400
On Oct 18, 2004, at 3:40 PM, Chandra Khan wrote:
The UNIX process in question does an ioctl(my_dev) and, once in kernel
space, sits on a semaphore_wait(). Because this process is
ptrace-attached to a child process, and that child process gets a
signal (as part of the design), I expect that the parent process will
get a SIGCHLD, and in doing so, pop out of the semaphore_wait() with a
KERN_ABORTED.
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.
It works. Unfortunately, not always.
Especially when there is a lot of context switching between the parent
and child (as opposed to the parent mostly sleeping), things dont work
as I expect. While the SIGCHLD is delivered and the custom SIGCHLD
handler *does* run (asynchronously), the parent process never aborts
its semaphore_wait().
This is the part that confused me (or led me to believe that you had
more than one thread in the parent). 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.
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.
--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