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

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

On Mon, Oct 16, 2006 at 02:59:48AM -0700, Ulrich Drepper (drepper@redhat.com) wrote:
> Evgeniy Polyakov wrote:
> >One can set number of events before the syscall and do not remove them
> >after syscall. It can be updated if there is need for that.
> 
> Nobody doubts that it is possible.  But it is
> 
> a) potentially much expensive
> 
> and
> 
> b) an alien concept
> 
> to have the signal mask to set during the wait call implicitly. 
> Conceptually it doesn't even make sense.  This is no event to wait for. 
>  It a parameter for the specific wait call, just like the timeout.  And 
> I fortunately haven't seen you proposing to pass the timeout value 
> implicitly.

Because timeout has it's meaning for syscall processing, but signals are
completely separated objects. Why do you want to allow to queue signals
_and_ add 'temporal' signal mask for syscall? Just use one way - queue
them all.
 
> >>Not good enough?  It does exactly what it is supposed to do.  What can 
> >>there be "not good enough"?
> >
> >Not to move signals into special case of events. If poll() can not work
> >with them it does not mean, that they need to be specified as additional
> >syscall parameter, instead change poll() to work with them, which can be
> >easily done with kevents.
> 
> You still seem to be completely missing the point.  The signal mask is 
> no event to wait for.  It has nothing to do with this that ppoll() takes 
> the signal mask as a parameter.  The signal mask is a parameter for the 
> wait call just like the timeout, not more and not less.

That's where we have different opinioins (among others places :) - I do
not agree that signals are parameters for syscall, I insist that is is
usual events. ppoll() shows us that there is no difference between
signal reported as usual user - syscall returns and we can check if
something was changed (signal was delivered or even was fired), it does
not differ from the case when syscall returns and we check what event it
reports first - ready signal or some other event.
 
> >Do not mix warm and soft - waiting for some period is not equal to
> >syscall timeout. Waiting is possible with timer kevent user (although
> >only relative timeout, can be changed to support both, not a big
> >problem).
> 
> That's what I'm saying all the time.  Of course it can be supported. 
> But for this the timeout parameter must be a timespec pointer.  Whatever 
> you could possibly mean by "do not mix warm and soft" I cannot possibly 
> imagine.  Fact is that both relative and absolute timeouts are useful. 
> And that for absolute timeouts the change of the clock has to be taken 
> into account.

They are usefull for special waiting, but not for waiting when syscall
is called. The former is supported by timer notifications, the latter -
by syscall parameter. We can add support for absolute timer
notifications as addon to relative ones. But using there timeval
structure is not accessible, since it has different sizes on different
arches, so there will be problems with 32/64 arches like x86_64.
Instead it is possible to use u32/u32 structure for sec/nsec, like what
is used for relative timeouts.
 
> >I'm quite sure that absolute timeouts are very usefull, but not as in
> >the case of waiting for syscall completeness. In any way, kevent can be
> >extended to support absolute timeouts in it's timer notifications.
> 
> That's not the same.  If you argue that then the syscall should have no 
> timeout parameter at all.  Fact is that setting up a timer is not for 
> free.  Since the timeout is used all the time having a timeout parameter 
> is the right answer.  And if you do this then do it right just like 
> every other syscall other than poll: use a timespec object.  This gives 
> flexibility without measurable cost.

It does not introduce any flexibility, since syscall does not have a
parameter to specify absolute or relative timeout has been provided.
That's one.
I do argue that syscall must have timout parameter, since it is related
to syscall behaviour but not to events syscall is working with - which is
completely different things: syscall must be interrupted after some time
to allow to fail operation or perform other tasks, but timer event can
be fired in any time in the future, syscall should not care about
underlaying events. That's two.
You say "every other syscall other than poll" - but even aio_suspend()
and friends use relative timeouts (although glibc converts them into 
absolute to be used with pthread_cond_timedwait), so why do you propose 
to use wariable sized structure (even if it is transferred almost for 
free in syscall) instead of usual timeout specified in 
seconds/nanoseconds/anything? That's three.

> -- 
> ➧ 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/