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/
This archive was generated by hypermail 2b29 : Sat Jun 30 2001 - 21:00:21 EST