[vlc-devel] [PATCH] android: threads support

[Rémi Denis-Courmont]

On Fri, 05 Oct 2012 12:44:00 +0200, Rafaël Carré <funman at videolan.org>
wrote:
> Le 05/10/2012 09:03, Rémi Denis-Courmont a écrit :
>> On Thu, 04 Oct 2012 23:22:09 +0200, Rafaël Carré <funman at videolan.org>
>> wrote:
>>>>> +/**
>>>>> + * Initializes a semaphore.
>>>>> + */
>>>>> +void vlc_sem_init (vlc_sem_t *sem, unsigned value)
>>>>
>>>> This is not going to interoperate with cancellation.
>>>
>>> What do you mean?
>>>
>>> Some of those are mandated to be cancellation points?
>> 
>> sem_wait() and pthread_rwlock_(rd|wr)lock().
> 
> 
>
http://pubs.opengroup.org/onlinepubs/000095399/functions/xsh_chap02_09.html#tag_02_09_05_02
> 
> Only sem_wait() is mandatory and cancellation is handled.

It is handled in a very energy-inefficient manner, compared to the
existing VLC implementation.

And R/W locking may be a cancellation point really means R/W locking ought
to be a cancellation point in the slow/contention path.

>>>>> +    if (lock) {
>>>>> +        if (!self)
>>>>> +            vlc_mutex_lock(lock);
>>>>
>>>> I don't see what warrants that the mutex still exists at this point.
>>>
>>> vlc_join(thread_id) has not been called yet.
>> 
>> So the thread handle exists. But my question concerns the mutex.
> 
> Well we assume if the thread was waiting on a condition, the condition's
> mutex has not been destroyed.

Nothing proves that the thread is waiting on the condition variable. All
you know, at the time lock is fetched, the thread has not yet reset lock to
NULL. That does not mean the thread is still waiting. That definitely does
not mean the thread will still be waiting a few cycles later when
pthread_cond_broadcast() gets invoked.

I cannot see any warranty that lock and cond pointers are valid.

Also, lock pointer seems useless in this business.

-- 
Rémi Denis-Courmont
Sent from my collocated server