[gst-devel] thread-safe v. non-thread-safe API
ds at schleef.org
Thu Dec 9 18:41:11 CET 2004
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
- Do application developers actually want to do this?
- Are there any example applications where a thread-safe is
- 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?
- 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.
More information about the gstreamer-devel