Re: [take19 0/4] kevent: Generic event handling mechanism.

[Evgeniy Polyakov <johnpol@2ka.mipt.ru>]

On Thu, Oct 05, 2006 at 07:45:23AM -0700, Ulrich Drepper (drepper@redhat.com) wrote:
> Evgeniy Polyakov wrote:
> > And you can add/remove signal events using existing kevent api between
> > calls.
> 
> That's far more expensive than using a mask under control of the program.

In context you have cut, one updated signal mask between calls to event
delivery mechanism (using for example signal()), so it has exactly the
same price.
 
> > And creating special cases for usual events is bad.
> > There is unified way to deal with events in kevent -
> > add/remove/modify/wait on them, signals are just usual events.
> 
> How can this be unified?  The installment of the temporary signal mask
> is unlike the handling of signal for the purpose of reporting them
> through the signal queue.  It's equally completely new functionality.
> Don't kid yourself in thinking that because this is signal stuff, too,
> you're "unifying" something.  The way this signal mask is used has
> nothing whatsoever to do with the delivering signals via the event
> queue.  For the latter the signals always must be blocked (similar to
> sigwait's requirement).
> 
> As a result it means you want to introduce a new mechanism for the event
> queue instead of using the well known and often used method of
> optionally passing a signal mask to the syscall.  That's just insane.

I created it just because I think that POSIX workaround to add signals
into the syscall parameters is not good enough.
Exactly with the same logic I created kevent to drive AIO completeness,
to work with socket notifications and timers and so on.
All above (listio(), poll(), setitimer() and so on) are known and good 
interfaces, but practice shows that having one interface, which can 
easily work with all existing cases is much more convenient than having 
tons of them.

So, yes, I do introduce new mechanism to solve signal problem here, just
because I think all existing have some limitations or problems.

> > I think you wanted to say, that 'all event mechanism except the most
> > commonly used poll/select/epoll use timespec'.
> 
> Get your facts straight.  select uses timeval which is just the
> predecessor of of timespec.  And epoll is just (badly) designed after
> poll.  Fact is therefore that poll plus its spawn is the only interface
> using such a timeout method.

And it was designed very good, although it looks like we disagree a bit
here...

> > I designed it to be similar to poll(), it is really good interface.
> 
> Not many people agree.  All the interfaces designed (not derived) in the
> last years take a timespec parameter.
> 
> Plus, you chose to ignore all the nice things using a timespec allow you
> like absolute timeout modes etc.  See the clock_nanosleep()  interface
> for a way this can be useful.

You again cut my explanation on why just pure timeout is used.
We start a syscall, which can block forever, so we want to limit it's
time, and we add special parameter to show how long this syscall should
run. Timeout is not about how long we should sleep (which indeed can be
absolute), but how long syscall should run - which is related to the 
time syscall started.

> -- 
> ➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖

-- 
	Evgeniy Polyakov