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

[David Schleef]

Wim,

Benjamin and I have been waiting for some time for you to
start discussing core issues.  The two of us discuss such
things in #gstreamer quite frequently, and have argued about
many issues over the last few months, and have come to
agreement on most things.

In order to jumpstart a conversation, here's some questions
and critiques of what I understand of your plans.  (Which,
I might add, are not particularly well documented.) From the
viewpoint of an application, what is the benefit of having a
thread-safe API?  In particular,

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

 - Do application developers actually want to do this?

 - Are there any example applications where a thread-safe is
   necessary?

 - 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?

Other questions:

 - Elements emit signals to be handled by the application.  How
   does the application specify which thread the signal should
   be marshalled in, and how do you get the signal from the
   element thread to the application thread?

 - How much code needs to be added to an application to deal
   with a thread-safe API?  You mentioned somewhere that some
   functions/fields must only be accessed while holding a lock --
   does an application have to deal with this?

 - Do elements need to be written with reentrancy in mind?  If
   not, how are you planning to guarantee that get_property()
   or change_state() are not called while get/chain/loop() is
   executing?  If you simply wait for the gst/chain/loop() to
   complete, you may be waiting for a significant amount of
   time, thus potentially blocking the GUI thread.
   

 

dave...