[lkml]   [2005]   [Aug]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRE: FW: [RFC] A more general timeout specification
>From: Roman Zippel []
>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
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-09-01 00:32    [W:0.037 / U:7.968 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site