On Sun, 2 Sep 2007, Oleg Nesterov wrote:
> We can optimize this later, using a "clever" wait_queue_func_t if needed.
Good idea. Will do ...
- Davide
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
On 09/02, Oleg Nesterov wrote:
>
> Small problem: unless I missed something, signalfd_deliver() and
> sys_signalfd()
> should use wake_up_all(), not wake_up() which implies nr_exclusive == 1.
>
> It is possible that we have multiple threads waiting on ->signalfd_wqh with
> the the different
On 09/01, Davide Libenzi wrote:
>
> I'm playing at the moment with this patch, that recall Ben's idea of
> attaching to the sighand only during read/poll, and calling dequeue_signal()
> only with "current". This simplifies the signalfd logic quite a bit.
> If this patch is applied, a task
On 09/01, Davide Libenzi wrote:
I'm playing at the moment with this patch, that recall Ben's idea of
attaching to the sighand only during read/poll, and calling dequeue_signal()
only with current. This simplifies the signalfd logic quite a bit.
If this patch is applied, a task calling
On Sun, 2 Sep 2007, Oleg Nesterov wrote:
We can optimize this later, using a clever wait_queue_func_t if needed.
Good idea. Will do ...
- Davide
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
While I was in vacation, I noticed that more "tsk == current" check were
added to the signal logic because of the way signalfd fetches other task
signals.
I'm playing at the moment with this patch, that recall Ben's idea of
attaching to the sighand only during read/poll, and calling
6 matches
Mail list logo
