[vlc-devel] [PATCH] HLS: don't signal dl thread out of the blue in Close()

[Frederic YHUEL]

On Thu, Jun 28, 2012 at 12:22 PM, Rémi Denis-Courmont <remi at remlab.net> wrote:
> On Wed, 27 Jun 2012 20:55:15 +0200, Jean-Baptiste Kempf <jb at videolan.org>
> wrote:
>> I think some of those good advice should be on the wiki, on the
>> check-before-sending-for-review page.
>
> The VLC threading subsystem has (always) been modeled after POSIX threads.
> There is no point in writing duplicated sub-standard VLC-specific
> documentation for those generic C programming paradigms. Indeed, any
> programmer familiar with POSIX threads should be able to use VLC threads
> easily. Conversely, any programmer unfamiliar with threading can be
> referred to generic POSIX threads quality documentation (e.g. books), to
> learn to program not only for VLC but for many other C projects.
>
> Furthermore, reference to an external standard provides a sane
> specification for what the semantics should be. Some VLC-specific helper
> functions have been plagged with vague definitions and changing semantics
> across versions and developers (e.g. string processing): I want to avoid
> that problem whenever possible.
>

However, maybe it would be wise to warn people that some modules in
VLC don't use threads properly. For exemple, we can find the following
pattern in a few modules:

    vlc_mutex_lock( &w->cond  );
    vlc_cond_signal(&w->cond );
    vlc_mutex_unlock( &w->cond );

IOW, signaling "out of the blue", without modifying the condition
variable's predicate while the lock is held.

audio_output/auhal.c
access_output/rtmp.c
media_library/ml_watch.c
access/rtmp/rtmp_amf_flv.c
access/rtmp/access.c

are such modules, where one can find this pattern.

Also, links with good documentation about threading could be nice,
IMHO. How to avoid deadlock? Wether to use fine-grained or
coarsed-grained locking? I think it's not that easy to find good
documentation about that subject.

Some articles like this one:
http://queue.acm.org/detail.cfm?id=2088916 are nice but also somewhat
confusing:

> [WIth C11] to ensure data-race-freedom, it suffices to ensure that synchronization-free code sections that run at the same time don’t both write, or read and write, the same variables.

This is very cool. And with C99?

Best regards
Frédéric