Message-ID: <20061016072321.GA17735@2ka.mipt.ru>
Date:	Mon, 16 Oct 2006 11:23:22 +0400
From:	Evgeniy Polyakov <johnpol@....mipt.ru>
To:	Ulrich Drepper <drepper@...hat.com>
Cc:	Ulrich Drepper <drepper@...il.com>,
	lkml <linux-kernel@...r.kernel.org>,
	David Miller <davem@...emloft.net>,
	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 Sun, Oct 15, 2006 at 03:43:39PM -0700, Ulrich Drepper (drepper@...hat.com) wrote:
> Evgeniy Polyakov wrote:
> >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.
> 
> No, it does not.  If the signal mask is recomputed by the program for 
> each new wait call then you have a lot more work to do when the signal 
> mask is implicitly specified.

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.
 
> >I created it just because I think that POSIX workaround to add signals
> >into the syscall parameters is not good enough.
> 
> 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 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.
> 
> I know very well what a timeout is.  But the way the timeout can be 
> specified can vary.  It is often useful (as for select, poll) to specify 
> relative timeouts.
> 
> But there are equally useful uses where the timeout is needed at a 
> specific point in time.  Without a syscall interface which can have a 
> absolute timeout parameter we'd have to write as a poor approximation at 
> userlever
> 
>     clock_gettime (CLOCK_REALTIME, &ts);
>     struct timespec rel;
>     rel.tv_sec = abstmo.tv_sec - ts.tv_sec;
>     rel.tv_nsec = abstmo.tv_sec - ts.tv_nsec;
>     if (rel.tv_nsec < 0) {
>       rel.tv_nsec += 1000000000;
>       --rel.tv_sec;
>     }
>     if (rel.tv_sec < 0)
>       inttmo = -1;  // or whatever is used for return immediately
>     else
>       inttmo = rel.tv_sec * UINT64_C(1000000000) + rel.tv_nsec;
> 
>      wait(..., inttmo, ...)

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

> Not only is this much more expensive to do at userlevel, it is also 
> inadequate because calls to settimeofday() do  not cause a recomputation 
> of the timeout.
> 
> See Ingo's RT futex stuff as an example for a kernel interface which 
> does it right.

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.

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