Messages in this thread | | | Date | Fri, 29 Jun 2001 02:29:11 -0700 | From | Dan Kegel <> | Subject | Re: A signal fairy tale |
| |
Christopher Smith wrote: > > At 07:57 PM 6/27/2001 -0700, Daniel R. Kegel wrote: > >From: Christopher Smith <x@xman.org> > > >I guess the main thing I'm thinking is this could require some significant > > >changes to the way the kernel behaves. Still, it's worth taking a "try it > > >and see approach". If anyone else thinks this is a good idea I may hack > > >together a sample patch and give it a whirl. > > > >What's the biggest change you see? From my (two-martini-lunch-tainted) > >viewpoint, it's just another kind of signal masking, sorta... > > Yeah, the more I think about it, the more I think this is just another > branch in the signal delivery code. Not necessarily too huge a change. I'll > hack on this over the weekend I think.
Cool, have fun!
Feature checklist for future reference:
If sigopen() has been called, and the file descriptor is still open, sigaction(x, 0, &foo) should show foo != SIG_DFL for compatibility with the traditional signal allocation scheme.
If sigopen() has been called, and the file descriptor is still open, sending a signal to the thread (or if posix, the process) that called sigopen() should cause the signal to stick until picked up by read(), or until close() is called on the fd(), in which case it will be delivered or picked up as normal.
sigaction(x, &foo, 0) should return EBUSY if fd=sigopen(x) has been called but close(fd) has not yet been called.
Pseudocode:
sigemptyset(&s); sigaddset(SIGUSR1, &s); fd=sigopen(&s); m=read(fd, buf, n*sizeof(siginfo_t)) close(fd);
should probably be equivalent to
sigemptyset(&s); sigaddset(SIGUSR1, &s); struct sigaction newaction, oldaction; newaction.sa_handler = dummy_handler; newaction.sa_flags = SA_SIGINFO; newaction.sa_mask = 0; sigaction(SIGUSR1, &newaction, &oldaction); for (i=0; i<n; i++) if (sigwaitinfo(&s, buf+i)) break; m = n * sizeof(siginfo_t); sigaction(SIGUSR1, &oldaction, 0);
(apologies if any of the above is wrong)
But, um, Chris, could you check your library code to make sure you did the sigaction stuff? Could it be that you forgot that, and if you did that properly, the main application would notice that you'd allocated a signal, and not suck up your signals?
- Dan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |