[vlc-devel] [PATCH] src: darwin/thread: reimplement monotonic clock for darwin

[David Fuhrmann]

Am 31.12.2013 um 16:21 schrieb Rémi Denis-Courmont <remi at remlab.net>:

> Le mardi 31 décembre 2013, 14:45:49 David Fuhrmann a écrit :
>> Am 31.12.2013 um 13:01 schrieb Rémi Denis-Courmont <remi at remlab.net>:
>>> Le mardi 31 décembre 2013, 12:30:31 David Fuhrmann a écrit :
>>>> Am 31.12.2013 um 12:19 schrieb Rémi Denis-Courmont <remi at remlab.net>:
>>>>> Le mardi 31 décembre 2013, 11:47:46 david.fuhrmann at gmail.com a écrit :
>>>>>> From: David Fuhrmann <david.fuhrmann at googlemail.com>
>>>>>> 
>>>>>> This is based on code which was silently removed in
>>>>>> 0f9a94f2183fc6c6e9ce8b77eb497aab160cbbbd and
>>>>>> 45c2bc0811cc2d9fe8e11448a05742d7ff6da1d8.
>>>>> 
>>>>> This is based on code that silently broke condition variable clock
>>>>> selection and silently breaks clock selection back again.
>>>> 
>>>> I already told that you cannot do any "clock selection" on darwin.
>>> 
>>> And that is why you cannot use any other clock.
>> 
>> Why do you think that I am trying to use any "other" clock?
> 
> Aren't you trying to switch from the so-called POSIX "real-time" clock to 
> Darwin monotonic clock? That seems to be the whole point of your patch.
> 
> (...)
>> gettimeofday is clearly not the right clock source, at least I did not got
>> any timing issues with any other application when changing the system time.
> 
> Of course, it is not optimal. That's why I put a #warning.
> 
>> Just because pthread_cond_timedwait is expecting a value calculated out of
>> gettimeofday, there is no reason to use this for the whole VLC.
> 
> We will have to agree to disagree. In my opinion, pthread_cond_timedwait() 
> *has* to work right, even if that conflicts with your desire to use the -
> otherwise superior- monotonic clock.
> 
>> In fact,
>> this value gets converted into a relative timeout again right at the
>> beginning of this function.
> 
> The patch assumes that the time value is relative to mdate(). If mdate() is 
> not the real-time clock any longer, then that ssumption is incorrect. In other 
> words, condition variables need clock selection.

Hi,

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). Same for nanosleep, 
as I already said.
So, this patch seems right and makes the clock usage consistent.

I still need to fix cond_init_daytime, through.

With best regards,
David