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

[Evgeniy Polyakov]

On Wed, Oct 04, 2006 at 10:20:44AM -0700, Ulrich Drepper (drepper@xxxxxxxxxx) wrote:
> Evgeniy Polyakov wrote:
> > It is completely possible to do what you describe without special
> > syscall parameters.
> 
> First of all, I don't see how this is efficiently possible.  The mask
> might change from call to call.

And you can add/remove signal events using existing kevent api between
calls.

> Second, hasn't it sunk in that inventing new ways to pass parameters is
> bad?  Programmers don't want to learn new ways for every new interface.
>  Reuse is good!

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.

> This applies to the signal mask here.
> 
> But there is another parameter falling into that category and I meant to
> mention it before: the timeout value.  All other calls except poll and
> especially all modern interfaces use a timespec pointer.  This is the
> way times are kept in userland code.  Don't try to force people to do
> something else.
> 
> Using a timespec also has the advantage that we can add an absolute
> timeout value mode (optional) instead of the relative timeout value.
> 
> In this context, we should/must be able to specify which clock the
> timeout is for (not as part of the wait call, but another control
> operation perhaps).  It's important to distinguish between
> CLOCK_REALTIME and CLOCK_MONOTONE.  Both have their use.

I think you wanted to say, that 'all event mechanism except the most
commonly used poll/select/epoll use timespec'.
I designed it to be similar to poll(), it is really good interface.
Nature of the waiting is to wait for some time, so I put there that
'some time'.

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



-- 
	Evgeniy Polyakov
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/