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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
