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 159566 - [PATCH] Race conditions in deep_notify
[PATCH] Race conditions in deep_notify
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
git master
Other Linux
: Normal major
: 0.9.x
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2004-11-26 16:17 UTC by Wim Taymans
Modified: 2005-07-15 16:30 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
patch to lock the deep_notify signals (1.04 KB, patch)
2004-11-26 18:30 UTC, Wim Taymans 		accepted-commit_now Details | Review

Description Wim Taymans 2004-11-26 16:17:08 UTC 
When running two threads that signal property changes, some of the deep_notify
messages get mangled or just disappear. A test app will be submitted to show the
problem.
Comment 1 Wim Taymans 2004-11-26 18:30:21 UTC 
Created attachment 34166 [details] [review]
patch to lock the deep_notify signals

This adds a recursive lock around the deep_notify signals
Comment 2 Benjamin Otte (Company) 2004-11-28 05:43:52 UTC 
Don't we get deadlocks from this if someone sets a property in a deep_notify
callback?

If there's no deadlocks the patch is ok, if you add a comment about why it's
needed to gstobject.c - it's a crude hack after all.
Comment 3 Wim Taymans 2004-12-15 09:15:59 UTC 
It's a recursive lock. A finer patch would just use a classwide lock instead of
a global lock.
Comment 4 Ronald Bultje 2005-03-25 19:05:20 UTC 
Wim, was this applied? Please apply it, including your test app that you are
talking about in the opening comment.
Comment 5 Andy Wingo 2005-07-15 16:30:26 UTC 
This is fixed in HEAD with the class lock, closing.