[vlc-devel] commit: atmo filter: disable until it is fixed ( Rémi Denis-Courmont )

[Rémi Denis-Courmont]

Le dimanche 30 août 2009 23:14:39 André Weber (atmo), vous avez écrit :
> Hi Rémi,
>
> >  #if defined(_ATMO_VLC_PLUGIN_)
> > +#error This makes no sense!
> >     vlc_mutex_lock( &m_WakeupLock );
> >     vlc_cond_signal( &m_WakeupCond );
> >     vlc_mutex_unlock( &m_WakeupLock );
>
> mmh - but there are other modules - doing this the same way - from there
> I "copied" the usage of vlc_cond_signal with the mutex.
> Usually for my use cases I wouldn't need the extra mutex - but the
> vlc_cond_timedwait, (or vlc_cond_wait) - expect a mutex which
> they can unlock and lock.

I think you don't understand how condition variables work. It's not the same 
as a Windows event.

> f.e. auhal.c, alsa.c - doing it also that way - the only difference to my
> code seems that this code parts are locking / unlocking the mutex also
> around the call to "vlc_cond_wait" (which does internaly unlock the mutex,
> before really waiting and reaquire the lock after waiting.)

And they're both buggy. I fixed ALSA.

> So my code seems to miss the Lock / Unlock - around the
> vlc_cond_timedwait(..)? to avoid the deadlock problem? Or is there a way to
> wait for a condition - without a extra mutex? inside VLC code.

There are two potential reason why this dead locks. First, the state which the 
condition variable is associated with, is not properly protected by the lock. 
Second, you are inconditionally waiting on the condition, even if the state is 
already correct. Either way, you might end up loosing signals, then getting 
stuck forever in waiting.

-- 
Rémi Denis-Courmont
http://www.remlab.net/