After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 322628 - document thread-unsafety of gst_value_foo() + gst_value_register_foo_func()
document thread-unsafety of gst_value_foo() + gst_value_register_foo_func()
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
git master
Other Linux
: Normal normal
: 0.10.4
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Reported: 2005-11-28 09:44 UTC by Tim-Philipp Müller
Modified: 2006-03-07 11:47 UTC
See Also:
GNOME target: ---
GNOME version: ---

Description Tim-Philipp Müller 2005-11-28 09:44:30 UTC
The following functions use g_array_index():


while the following functions use g_array_append()


all accessing arrays with file scope unprotected by mutexes. 

gst_value_register_foo_func() might trigger a g_realloc() within GLib; if at the
same time a gst_value_foo() operation is going on in another thread, the memory
it accesses from g_array_index() has become invalid and bad things will happen.

This is a bit of a theoretical problem, but IMHO we should either make things
thread-safe or document the thread unsafety of these functions.

Of course this is not a problem for GStreamer itself. In GStreamer, all GstValue
stuff is registered from gst_init(), and at that point we don't need to worry
about thread-safety yet.

However, the GstValue API is public, and any application or plugin or library
built on top of GStreamer is free to use it, and there is AFAICS no way to
guarantee for these users that they can register their stuff in a context where
thread-safety is not an issue (e.g. in case of a plugin loaded later).

Locking might be undesirable for performance reasons in functions like these,
but given the context they are usually used from (gst_caps_*) I find it hard to
believe that the performance impact of locking is actually significant here
(pure guesswork of course).
Comment 1 Wim Taymans 2006-03-07 10:10:10 UTC
No locking needed in GstValue. We need to add some comments to the docs stating the non-threadsafeness of these functions.
Comment 2 Tim-Philipp Müller 2006-03-07 11:47:51 UTC

 2006-03-07  Tim-Philipp Müller  <tim at centricular dot net>

       * gst/gstvalue.c:
         Document thread-unsafety of gst_value_register_foo_func()
         when used at the same time as gst_value_foo() (#322628).