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

[Ulrich Drepper]

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.


> 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 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.


> 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.

-- 
â Ulrich Drepper â Red Hat, Inc. â 444 Castro St â Mountain View, CA â

Attachment: signature.asc
Description: OpenPGP digital signature