Messages in this thread | | | Subject | RE: FW: [RFC] A more general timeout specification | Date | Wed, 31 Aug 2005 15:15:12 -0700 | From | "Perez-Gonzalez, Inaky" <> |
| |
>From: Roman Zippel [mailto:zippel@linux-m68k.org] >On Wed, 31 Aug 2005, Perez-Gonzalez, Inaky wrote: > >> + flags = tp->clock_id & TIMEOUT_FLAGS_MASK; >> + clock_id = tp->clock_id & TIMEOUT_CLOCK_MASK; >> + >> + result = -EINVAL; >> + if (flags & ~TIMEOUT_RELATIVE) >> + goto out; >> + >> + /* someday, we should support *all* clocks available to us */ >> + if (clock_id != CLOCK_REALTIME && clock_id != CLOCK_MONOTONIC) >> + goto out; >> + if ((unsigned long)tp->ts.tv_nsec >= NSEC_PER_SEC) >> + goto out; > >Why is that needed in a _general_ timeout API? What exactly makes it so >useful for everyone and not just more complex for everyone?
Because if a system call gets a timeout specification it needs to verify its correctness first. Instead of doing that at the point where it goes to sleep, that could be deep in an atomic section, we provide a separate function [timeout_validate()] which is the one you mention, to do that.
Usefulness: (see the rationale in the patch), but in a nutshell; most POSIX timeout specs have to be absolute in CLOCK_REALTIME (eg: pthread_mutex_timed_lock()). Current kernel needs the timeout relative, so glibc calls the kernel/however gets the time, computes relative times and syscalls. Race conditions, overhead...etc.
This mechanism supports both. That's why it is more general.
-- Inaky - 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/
| |