[vlc-devel] [PATCH] src: darwin/thread: reimplement monotonic clock for darwin
remi at remlab.net
Mon Jan 6 20:10:33 CET 2014
Le lundi 6 janvier 2014, 15:16:12 David Fuhrmann a écrit :
> I asked on the Apple dev forums about this topic, and an Apple developer
> confirmed that both pthread_cond_timedwait and
> pthread_cond_timedwait_relative_np always make use of the monotonic clock
> (mach absolute time).
I digress but...
As far as absolute deadlines are concerned, that statement does not make much
sense. pthread_cond_timedwait() has to follow the real-time clock (unless
clock selection is supported and another clock has been selected explicitly).
Otherwise you get weird bugs. For instance, a VLM "schedule" input would start
and stop at the wrong time in the event that the user manually corrected the
system time after (s)he scheduled the VLM input. Concretely, if you adjust
clock of your home VCR, you expect the VCR to use the adjusted time for the
already pending recordings.
Of course, it is possible for the implement real-time and monotonic clock
using the same raw hardware clock and the same linear conversions. Only the
origins (in linear algebraic sense) have to be different. But that is an
implementation detail, irrelevant to VLC.
> Same for nanosleep, as I already said.
Sure, nanosleep() is allowed to use the monotonic clock, and
pthread_cond_timedwait_relative_np() can use whatever since it is not even in
the specification. But pthread_cond_timedwait() cannot.
Anyway, to the point:
> So, this patch seems right and makes the clock usage consistent.
> I still need to fix cond_init_daytime, through.
That is a convoluted way of expressing that the patch is wrong, as I said.
More information about the vlc-devel