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

[Ulrich Drepper]

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.


> 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"?


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


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.

--
â Ulrich Drepper â Red Hat, Inc. â 444 Castro St â Mountain View, CA â
-
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/