GNOME Bugzilla – Bug 159852
[PATCH] [api] g_signal_emit thread safety issues
Last modified: 2004-12-22 21:47:04 UTC
testsuite/threads/signal2 shows the problem. This method of firing a signal and calling a virtual function is used in the iterate method in gstbin.c, resulting in weird assertions failing from time to time. Since this bug can only be triggered in a small window, it is hard to reproduce.
Created attachment 34282 [details] [review] patch to lock iterate signal This patch adds a recursive lock around the iterate signal to mask the problem.
Created attachment 34284 [details] [review] don't lock in the iterate virtual method A slightly less intrusive patch that only locks around the signal emision but not on the actual iterate function.
Both patches have a problem. The first makes it so only one bin at a time can iterate which makes using multiple threads kinda useless and the second breaks applications that use post-signals to update the UI. I'm not sure there are any though, but I remember telling people to use the iterate signal for that.
running into this *a lot* with the ogg muxer and multiple input pads. marking as blocker.
Dude, you're suggesting to apply an incredibly invasive patch that has been tested by one or two persons.
Created attachment 35051 [details] [review] still use signal handler but unlock in bin iterate This patch still uses the signal emision to trigger the virtual function. The lock is put around the signal emit to protect against unsafe glib refcounting but the lock is released in the iterate_func. This should make multiple bins iterate simultaneously.
commited