>From: Roman Zippel [mailto:[email protected]]
>On Wed, 31 Aug 2005, Perez-Gonzalez, Inaky wrote:
>
>> Hmm, I cannot think of more ways to specify a timeout than how
>> long I want to wait (relative) or until when (absolute) and which
>> is the reference clock. And they don't seem broken to me, common
>> sense, in any case. Do you have any examples?
>
>You still didn't explain what's the point in choosing different clock
>sources for a _timeout_.
The same reasons that compel to have CLOCK_REALTIME or
CLOCK_MONOTONIC, for example. Or the need to time out on a
high resolution clock.
A certain application might have a need for a 10ms timeout,
but another one might have it on 100us--modern CPUs make that
more than possible. The precission of your time source permeates
to the precission of your timeout.
[of course, now at the end it is still kernel time, but the
ongoing revamp work on timers will change some of that, one
way or another].
>> Different versions of the same function that do relative, absolute.
>> If I keep going that way, the reason becomes:
>>
>> sys_mutex_lock
>> sys_mutex_lock_timed_relative_clock_realtime
>> sys_mutex_lock_timed_absolute_clock_realtime
>> sys_mutex_lock_timed_relative_clock_monotonic
>> sys_mutex_lock_timed_absolute_clock_monotonic
>> sys_mutex_lock_timed_relative_clock_monotonic_highres
>> sys_mutex_lock_timed_absolute_clock_monotonic_highres
>
>Hiding it behind an API makes it better?
It certainly cuts out cruft and to my not-so-trained eye, makes it
cleaner and easier to maintain.
>You didn't answer my other question, let's assume we add such a timeout
>structure, what's wrong with converting it to kernel time (which would
>automatically validate it).
And again, that's what at the end this API is doing, convering it to
kernel time.
Give it a more "human" specification (timespec) and gets the job done.
No need to care on how long a jiffy is today in this system, no need
to replicate endlessly the conversion code, which happens to be
non-trivial (for the absolute time case--but still way more trivial
than userspace asking the kernel for the time, computing a relative
shift and dealing with the skews that preemption at a Murphy moment
could cause).
It is mostly the same as schedule_timeout(), but it takes the sleep
time in a more general format. As every other API, it is designed so
that the caller doesn't need to care or know about the gory details
on how it has to be converted.
-- 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]
| |
 |