RE: FW: [RFC] A more general timeout specification

[Perez-Gonzalez, Inaky]

>From: Roman Zippel [mailto:zippel@xxxxxxxxxxxxxx]
>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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/