GNOME Bugzilla – Bug 706831
composition: Release objects lock while forwarding an event
Last modified: 2014-01-06 10:49:33 UTC
There is no reason to keep it and in some rare cases it creates deadlocks as followed: t1: → Composition receives a flushing seek, it takes the OBJECTS_LOCK and fowards the flushing seek event upstream → adder receives the seek and set its collectpad to flushing This implies tacking STREAM_LOCK (collectpad) t2: → Collectpad has buffers ready, and has the STREAM_LOCK (collectpad) and is EOS, so it sends it downstream → The composition receives EOS, and needs to check if it is the actual EOS or not, thus need to take the OBJECTS_LOCK This create a deadlock, and in the first stage, we did not need the OBJECTS_LOCK to forward downstream the flushing seek, so do not take it.
Created attachment 253177 [details] [review] composition: Release objects lock while forwarding an event There is no reason to keep it and in some rare cases it creates deadlocks as followed: t1: → Composition receives a flushing seek, it takes the OBJECTS_LOCK and fowards the flushing seek event upstream → adder receives the seek and set its collectpad to flushing This implies tacking STREAM_LOCK (collectpad) t2: → Collectpad has buffers ready, and has the STREAM_LOCK (collectpad) and is EOS, so it sends it downstream → The composition receives EOS, and needs to check if it is the actual EOS or not, thus need to take the OBJECTS_LOCK This create a deadlock, and in the first stage, we did not need the OBJECTS_LOCK to forward downstream the flushing seek, so do not take it.
Review of attachment 253177 [details] [review]: The object lock should *never* be hold while sending a buffer, event, query or message.
Attachment 253177 [details] pushed as 8f3bb08 - composition: Release objects lock while forwarding an event
Created attachment 254322 [details] [review] composition: Never take the OBJECTS_LOCK when sending events We should never have the OBJECTS_LOCK when sending or receiving events. This lock is usefull only when we deal with children of composition, so it should be used exclusivly for that purpose It avoiding deadlocks
Created attachment 254323 [details] [review] composition: Never take the OBJECTS_LOCK when sending events We should never have the OBJECTS_LOCK when sending or receiving events. This lock is usefull only when we deal with children of composition, so it should be used exclusivly for that purpose Avoiding deadlocks
Review of attachment 254323 [details] [review]: Looks good but please make sure again that you don't introduce race conditions by releasing the lock for a short time, i.e. does code assume below that nothing has changed compared to before sending the event? If code assumes that, rewrite it or introduce a new lock.
Thibault?
commit 8f3bb083f8e59d9c541c4f80ed40a1b9c780e7dd Author: Thibault Saunier <thibault.saunier@collabora.com> Date: Mon Aug 26 16:26:31 2013 -0400 composition: Release objects lock while forwarding an event There is no reason to keep it and in some rare cases it creates deadlocks as followed: t1: → Composition receives a flushing seek, it takes the OBJECTS_LOCK and fowards the flushing seek event upstream → adder receives the seek and set its collectpad to flushing This implies tacking STREAM_LOCK (collectpad) t2: → Collectpad has buffers ready, and has the STREAM_LOCK (collectpad) and is EOS, so it sends it downstream → The composition receives EOS, and needs to check if it is the actual EOS or not, thus need to take the OBJECTS_LOCK This create a deadlock, and in the first stage, we did not need the OBJECTS_LOCK to forward downstream the flushing seek, so do not take it. https://bugzilla.gnome.org/show_bug.cgi?id=706831