On Thu, 15 Mar 2007, Ulrich Drepper wrote:
> On 3/7/07, Davide Libenzi wrote:
> > Let's do this. How about you throw this way one of the case that would
> > possibly break, and I test it?
>
> Since you make such claims I assume your signalfd() implementation
> considers a signal delivered once
On 3/7/07, Davide Libenzi wrote:
Let's do this. How about you throw this way one of the case that would
possibly break, and I test it?
Since you make such claims I assume your signalfd() implementation
considers a signal delivered once it is reported to an epoll() caller.
Right?
This is not
On 3/7/07, Davide Libenzi davidel@xmailserver.org wrote:
Let's do this. How about you throw this way one of the case that would
possibly break, and I test it?
Since you make such claims I assume your signalfd() implementation
considers a signal delivered once it is reported to an epoll()
On Thu, 15 Mar 2007, Ulrich Drepper wrote:
On 3/7/07, Davide Libenzi davidel@xmailserver.org wrote:
Let's do this. How about you throw this way one of the case that would
possibly break, and I test it?
Since you make such claims I assume your signalfd() implementation
considers a signal
On Wed, 7 Mar 2007, Jeremy Fitzhardinge wrote:
> Davide Libenzi wrote:
> > You have the *choice* to do that:
> >
> > 1) You want standard delivery only:
> >
> >- Just dont use signalfd
> >
> > 2) you want signalfd only:
> >
> >- Do a sigprocmask(SIG_BLOCK) of the same mask you pass to
Davide Libenzi wrote:
> You have the *choice* to do that:
>
> 1) You want standard delivery only:
>
>- Just dont use signalfd
>
> 2) you want signalfd only:
>
>- Do a sigprocmask(SIG_BLOCK) of the same mask you pass to signalfd
>
> If you want both, you can have it. Race free.
>
It's
On Wed, 7 Mar 2007, Ulrich Drepper wrote:
> On 3/7/07, Linus Torvalds <[EMAIL PROTECTED]> wrote:
> > > 1) You want standard delivery only:
> > >
> > >- Just dont use signalfd
> > >
> > > 2) you want signalfd only:
> > >
> > >- Do a sigprocmask(SIG_BLOCK) of the same mask you pass to
On Wed, 7 Mar 2007, Linus Torvalds wrote:
>
>
> On Wed, 7 Mar 2007, Davide Libenzi wrote:
> >
> > You have the *choice* to do that:
> >
> > 1) You want standard delivery only:
> >
> >- Just dont use signalfd
> >
> > 2) you want signalfd only:
> >
> >- Do a sigprocmask(SIG_BLOCK) of
On 3/7/07, Linus Torvalds <[EMAIL PROTECTED]> wrote:
> 1) You want standard delivery only:
>
>- Just dont use signalfd
>
> 2) you want signalfd only:
>
>- Do a sigprocmask(SIG_BLOCK) of the same mask you pass to signalfd
>
> If you want both, you can have it. Race free.
.. but maybe
On Wed, 7 Mar 2007, Davide Libenzi wrote:
>
> You have the *choice* to do that:
>
> 1) You want standard delivery only:
>
>- Just dont use signalfd
>
> 2) you want signalfd only:
>
>- Do a sigprocmask(SIG_BLOCK) of the same mask you pass to signalfd
>
> If you want both, you can
On Wed, 7 Mar 2007, Jeremy Fitzhardinge wrote:
> Davide Libenzi wrote:
> > If you think a signal as a generic event source, than you see how more
> > instances can attach to it and receive them.
> > You can have multiple signalfd with whatever sigmasks, even intersecting.
> > You can pass the
Davide Libenzi wrote:
> If you think a signal as a generic event source, than you see how more
> instances can attach to it and receive them.
> You can have multiple signalfd with whatever sigmasks, even intersecting.
> You can pass the fd around, w/out the fear that a standard signal delivery
On Wed, 7 Mar 2007, Jeremy Fitzhardinge wrote:
> Davide Libenzi wrote:
> > On Wed, 7 Mar 2007, Linus Torvalds wrote:
> >
> >
> >> On Wed, 7 Mar 2007, Stephen Rothwell wrote:
> >>
> >>> You probably need the queue anyway because the real time signals are
> >>> supposed to queue.
> >>>
Davide Libenzi wrote:
> On Wed, 7 Mar 2007, Linus Torvalds wrote:
>
>
>> On Wed, 7 Mar 2007, Stephen Rothwell wrote:
>>
>>> You probably need the queue anyway because the real time signals are
>>> supposed to queue.
>>>
>> Davide - the *real* problem is (I think) that you try to
On Wed, 7 Mar 2007, Linus Torvalds wrote:
> On Wed, 7 Mar 2007, Stephen Rothwell wrote:
> >
> > You probably need the queue anyway because the real time signals are
> > supposed to queue.
>
> Davide - the *real* problem is (I think) that you try to allow signals to
> be returned *both* by
On Wed, 7 Mar 2007, Stephen Rothwell wrote:
> 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
On Wed, 7 Mar 2007, Stephen Rothwell wrote:
>
> You probably need the queue anyway because the real time signals are
> supposed to queue.
Davide - the *real* problem is (I think) that you try to allow signals to
be returned *both* by signalfd() and as a real signal.
That's wrong, wrong,
On Tue, 6 Mar 2007 23:11:49 -0800 (PST) Davide Libenzi
wrote:
>
> On Wed, 7 Mar 2007, Stephen Rothwell wrote:
>
> > On Tue, 6 Mar 2007 17:36:56 -0800 (PST) Davide Libenzi
> > wrote:
> > >
> > > The read(2) call will read u32 signal numbers that landed over the
> > > signalfd. It returns the
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
On Wed, 7 Mar 2007, Stephen Rothwell wrote:
You probably need the queue anyway because the real time signals are
supposed to queue.
Davide - the *real* problem is (I think) that you try to allow signals to
be returned *both* by signalfd() and as a real signal.
That's wrong, wrong, wrong.
On Wed, 7 Mar 2007, Stephen Rothwell wrote:
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
On Wed, 7 Mar 2007, Linus Torvalds wrote:
On Wed, 7 Mar 2007, Stephen Rothwell wrote:
You probably need the queue anyway because the real time signals are
supposed to queue.
Davide - the *real* problem is (I think) that you try to allow signals to
be returned *both* by signalfd() and
Davide Libenzi wrote:
On Wed, 7 Mar 2007, Linus Torvalds wrote:
On Wed, 7 Mar 2007, Stephen Rothwell wrote:
You probably need the queue anyway because the real time signals are
supposed to queue.
Davide - the *real* problem is (I think) that you try to allow signals to
be
On Wed, 7 Mar 2007, Jeremy Fitzhardinge wrote:
Davide Libenzi wrote:
On Wed, 7 Mar 2007, Linus Torvalds wrote:
On Wed, 7 Mar 2007, Stephen Rothwell wrote:
You probably need the queue anyway because the real time signals are
supposed to queue.
Davide - the *real*
Davide Libenzi wrote:
If you think a signal as a generic event source, than you see how more
instances can attach to it and receive them.
You can have multiple signalfd with whatever sigmasks, even intersecting.
You can pass the fd around, w/out the fear that a standard signal delivery
On Wed, 7 Mar 2007, Jeremy Fitzhardinge wrote:
Davide Libenzi wrote:
If you think a signal as a generic event source, than you see how more
instances can attach to it and receive them.
You can have multiple signalfd with whatever sigmasks, even intersecting.
You can pass the fd around,
On Wed, 7 Mar 2007, Davide Libenzi wrote:
You have the *choice* to do that:
1) You want standard delivery only:
- Just dont use signalfd
2) you want signalfd only:
- Do a sigprocmask(SIG_BLOCK) of the same mask you pass to signalfd
If you want both, you can have it. Race
On 3/7/07, Linus Torvalds [EMAIL PROTECTED] wrote:
1) You want standard delivery only:
- Just dont use signalfd
2) you want signalfd only:
- Do a sigprocmask(SIG_BLOCK) of the same mask you pass to signalfd
If you want both, you can have it. Race free.
.. but maybe with more code
On Wed, 7 Mar 2007, Linus Torvalds wrote:
On Wed, 7 Mar 2007, Davide Libenzi wrote:
You have the *choice* to do that:
1) You want standard delivery only:
- Just dont use signalfd
2) you want signalfd only:
- Do a sigprocmask(SIG_BLOCK) of the same mask you pass
On Wed, 7 Mar 2007, Ulrich Drepper wrote:
On 3/7/07, Linus Torvalds [EMAIL PROTECTED] wrote:
1) You want standard delivery only:
- Just dont use signalfd
2) you want signalfd only:
- Do a sigprocmask(SIG_BLOCK) of the same mask you pass to signalfd
If you want
Davide Libenzi wrote:
You have the *choice* to do that:
1) You want standard delivery only:
- Just dont use signalfd
2) you want signalfd only:
- Do a sigprocmask(SIG_BLOCK) of the same mask you pass to signalfd
If you want both, you can have it. Race free.
It's only usefully
On Wed, 7 Mar 2007, Jeremy Fitzhardinge wrote:
Davide Libenzi wrote:
You have the *choice* to do that:
1) You want standard delivery only:
- Just dont use signalfd
2) you want signalfd only:
- Do a sigprocmask(SIG_BLOCK) of the same mask you pass to signalfd
If you
On Wed, 7 Mar 2007, Stephen Rothwell wrote:
> On Tue, 6 Mar 2007 17:36:56 -0800 (PST) Davide Libenzi
> 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
On Tue, 6 Mar 2007 17:36:56 -0800 (PST) Davide Libenzi
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
On Tue, 6 Mar 2007, Davide Libenzi wrote:
> This patch series implements a new signalfd() system call. I took part of
> the original Linus code (and you know how badly it can be broken :), and I
> added even more breakage ;)
I forgot to add that this requires the anonymous inode source
This patch series implements a new signalfd() system call. I took part of
the original Linus code (and you know how badly it can be broken :), and I
added even more breakage ;)
The patch had to be almost completely changed. This patch allows multiple
signalfd to listen for signals on the same
This patch series implements a new signalfd() system call. I took part of
the original Linus code (and you know how badly it can be broken :), and I
added even more breakage ;)
The patch had to be almost completely changed. This patch allows multiple
signalfd to listen for signals on the same
On Tue, 6 Mar 2007, Davide Libenzi wrote:
This patch series implements a new signalfd() system call. I took part of
the original Linus code (and you know how badly it can be broken :), and I
added even more breakage ;)
I forgot to add that this requires the anonymous inode source contained
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
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
40 matches
Mail list logo
