Messages in this thread |  | | | Subject | RE: FW: [RFC] A more general timeout specification | | Date | Wed, 31 Aug 2005 16:24:18 -0700 | | From | "Perez-Gonzalez, Inaky" <> |
| |
>From: Roman Zippel [mailto:zippel@linux-m68k.org] >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 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/
|  |