Messages in this thread | | | Date | Wed, 7 Mar 2007 23:38:33 +1100 | From | Stephen Rothwell <> | Subject | Re: [patch 1/4] signalfd v1 - signalfd core ... |
| |
On Tue, 6 Mar 2007 23:11:49 -0800 (PST) Davide Libenzi <davidel@xmailserver.org> wrote: > > On Wed, 7 Mar 2007, Stephen Rothwell wrote: > > > On Tue, 6 Mar 2007 17:36:56 -0800 (PST) Davide Libenzi <davidel@xmailserver.org> wrote: > > > > > > The read(2) call will read u32 signal numbers that landed over the > > > signalfd. It returns the size of the data copied, or zero if the sighand > > > we are attached to, has been detached. > > > > So what about signals that the user asked for a siginfo_t to be returned > > with? > > O-Ren: "You didn't think it was gonna be that easy, did you?" > B-Kiddo: "You know, for a second there, yeah, I kinda did." > > :) > > I could do that, since where I placed the signalfd_notify() I have the > siginfo. But that is going to make code a little more complex, since the > simple bitmaks needs to become a queue.
Then, of course, you have to think about how to get the siginfo_t out to the user process. Do you just return it from the read after the read that returns the signal number? If so, you need to know if the process did a compat read syscall read or a normal one ...
There may be a better solution.
You probably need the queue anyway because the real time signals are supposed to queue.
-- Cheers, Stephen Rothwell sfr@canb.auug.org.au http://www.canb.auug.org.au/~sfr/ [unhandled content-type:application/pgp-signature] | |