[gst-devel] thread-safe v. non-thread-safe API

[Iain *]

I don't know how relevant these answers are...
Partly cos I'm not sure of the issues.

>  - It is important that a GstPipeline (and all the elements it
>    owns) is able to be accessed _by an application_ from any
>    thread simultaneously?

Marlin likes doing it.

>  - Do application developers actually want to do this?
> 
>  - Are there any example applications where a thread-safe is
>    necessary?

Marlin. Marlin's pipelines are rather thread heavy cos of how things
are working (Sometimes I'm not sure why, but Benjamin has told me to
add threads and queues occasionally and that makes things work...maybe
these are just bugs in GStreamer that need to be fixed)

So yeah, Marlin has say a multi-threaded pipeline, and the GUI needs
to display a progress as it works through the pipeline, listening to
signals and value changes. These signals need to get communicated
somehow to the main gui thread, or it all falls to pieces.

>  - No, really.  How many applications will actually want to
>    frob with GStreamer from multiple threads simultaneously, and
>    how many of these cases cannot be handled by the _application_
>    keeping track of reentrancy?

Marlin handles the re-entrancy by catching events on the thread and
then forwarding it to the GUI thread via pipes and fancy tricks...

So while Marlin uses threads heavily, it is very easy to work around
the issues once you know what they are.

iain