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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



>From: Roman Zippel [mailto:[email protected]]
>On Wed, 31 Aug 2005, Perez-Gonzalez, Inaky wrote:
>
>> 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?

I cannot produce (top of my head) any other POSIX API calls that
allow you to specify another clock source, but they are there,
somewhere. If I am to introduce a new API, I better make it 
flexible enough so that other subsystems can use it for more stuff
other than...

>Why is not sufficient to just add a relative/absolute version,
>which convert the time at entry to kernel time?

...adding more versions that add complexity and duplicate
code in many different places (user-to-kernel copy, syscall entry 
points, timespec validation). And the minute you add a clock_id
you can steal some bits for specifying absolute/relative (or vice
versa), so it is almost a win-win situarion.

To summarize: thought about that, but it is fugly and not too practical.


Consider also his allows you to write extensions to POSIX or your
own user-level APIs that could allow (following the fusyn example) 
you to wait on a mutex with a timeout based off a monotonic clock, 
if you need it (or something that makes more sense than this--highres 
comes to mind). 

-- Inaky
-
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]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]
  Powered by Linux