Re: [patch 1/4] signalfd v1 - signalfd core ...

[Stephen Rothwell <sfr@canb.auug.org.au>]

[-- Attachment #1: Type: text/plain, Size: 1345 bytes --]

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/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]