lkml.org 
[lkml]   [2005]   [Aug]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRE: FW: [RFC] A more general timeout specification
Hi,

On Wed, 31 Aug 2005, Perez-Gonzalez, Inaky wrote:

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

Your patch basically only mentions fusyn, why does it need multiple clock
sources? Why is not sufficient to just add a relative/absolute version,
which convert the time at entry to kernel time?

bye, Roman
-
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/

\
 
 \ /
  Last update: 2005-09-01 01:04    [W:0.025 / U:47.592 seconds]
©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site