[Bug 742684] aggregator: Usage of GCond is racy.

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=742684
  GStreamer | gst-plugins-bad | git

Mathieu Duponchelle <mathieu.duponchelle> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mathieu.duponchelle at epitech
                   |                            |.eu

--- Comment #7 from Mathieu Duponchelle <mathieu.duponchelle at epitech.eu> 2015-01-10 20:27:38 UTC ---
(In reply to comment #0)
> Playing around with the new GstAggregator code, I get deadlocks with the
> aggregator thread stuck on I see a macro that does:
> 

It would be useful to have a test / example that shows these deadlocks, as
Thibault said we spent quite a lot of time working on thread safety in there
and had very intensive test cases running forever. The code has substantially
changed since then, and it would be wise that we rerun these specific tests to
ensure there has been no regression, but please share failing cases.

> g_mutex_lock()
> g_cond_broadcast();
> g_mutex_unlock();
> 
> This is always always always wrong. Because the g_cond_broadcast() may happen
> between the time when the actual condition is checked and the time when the
> g_cond_wait() is called, which results in the wait waiting forever.

I'm not sure why you're saying this, when the doc specifies :

It is good practice to lock the same mutex as the waiting threads while calling
this function, though not required.

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.