[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20061004045527.GB32267@2ka.mipt.ru>
Date: Wed, 4 Oct 2006 08:55:27 +0400
From: Evgeniy Polyakov <johnpol@....mipt.ru>
To: Ulrich Drepper <drepper@...il.com>
Cc: lkml <linux-kernel@...r.kernel.org>,
David Miller <davem@...emloft.net>,
Ulrich Drepper <drepper@...hat.com>,
Andrew Morton <akpm@...l.org>, netdev <netdev@...r.kernel.org>,
Zach Brown <zach.brown@...cle.com>,
Christoph Hellwig <hch@...radead.org>,
Chase Venters <chase.venters@...entec.com>
Subject: Re: [take19 0/4] kevent: Generic event handling mechanism.
On Tue, Oct 03, 2006 at 09:50:09PM -0700, Ulrich Drepper (drepper@...il.com) wrote:
> On 9/27/06, Evgeniy Polyakov <johnpol@....mipt.ru> wrote:
> \> I have been told in private what is signal masks about - just to wait
> >until either signal or given condition is ready, but in that case just
> >add additional kevent user like AIO complete or netwrok notification
> >and wait until either requested events are ready or signal is triggered.
>
> No, this won't work. Yes, I want signal notification as part of the
> event handling. But there are situations when this is not suitable.
> Only if the signal is expected in the same code using the event
> handling can you do this. But this is not always possible.
> Especially when the signal handling code is used in other parts of the
> code than the event handling. E.g., signal handling in a library,
> event handling in the main code. You cannot assume that all the code
> is completely integrated.
Signals still can be delivered in usual way too.
When we enter sys_ppoll() we specify needed signals as syscall
parameter, with kevents we will add them into the queue.
--
Evgeniy Polyakov
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists