[Bug 755169] dashdemux: can we have multiple seek events at the same time?

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=755169

--- Comment #54 from Vincent Penquerc'h <vincent.penquerch at collabora.co.uk> ---
Thanks, it was helpful.

I understand the deadlock now:

A seek event causes _stop_tasks to be called.
The manifest lock is held during this.
This causes the source elements to be stopped.
The source's pad stream lock is taken when its task stops.

In another thread, a buffer is being pushed to adaptivedemux from the source.
gst_adaptive_demux_stream_push_buffer takes the manifest lock.

This deadlocks.

I added the manifest lock in gst_adaptive_demux_stream_push_buffer to protect
calls to  gst_adaptive_demux_stream_get_presentation_offset and
gst_adaptive_demux_get_period_start_time, as well as uses of the demux object
(segment field).

This is complicated by the fact there is a second deadlock (so my original try
did not work, but I did not realize at the time I had been hitting a second
deadlock):

A source pushes a buffer.
This triggers gst_qtdemux_check_seekability to send a SEEKING query to check
for seekability.
This takes the api lock in gst_adaptive_demux_src_query

Another thread seeks, which ends up taking the api lock in
gst_adaptive_demux_src_event, then pauses the task that is busy pushing.


Taking out both:
- the api lock from gst_adaptive_demux_src_query
- the manifest lock from gst_adaptive_demux_stream_push_buffer

Fixes all deadlocks as far as I can tell.

This seems like a good argument to switch to the object lock instead of the
manifest lock, since we deadlock with the streaming thread here. This might
still cause trouble with the api lock when querying though.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.