Re: BSD signal not aborting semaphore_wait() in the kernel on an SMP
site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com 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. 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(). --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... On Oct 18, 2004, at 3:40 PM, Chandra Khan 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. 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. This email sent to site_archiver@lists.apple.com
participants (1)
-
Jim Magee