[Spice-devel] [client] streaming: Fix a race condition in the GStreamer frame display queue

[Christophe Fergeau]

Hey,

On Fri, Dec 23, 2016 at 04:07:49PM +0100, Francois Gouget wrote:
> When a frame is late we schedule its display right away with
> g_timeout_add(0, ...). This can result in display_frame() being called
> before g_timeout_add() returns. This would cause the timer_id being
> reset before schedule_frame() had set it so that it would then never be
> reset. So from that point schedule_frame() would always think a frame
> was being displayed and thus would not schedule any more frames
> resulting in a video freeze.
> display_frame() now takes the queues mutex before resetting timer_id
> eliminating the race.

Looks good to me, I think I'd explicitly mention the involved threads in
the commit log
"When a frame is late, we schedule its display right away with
g_timeout_add(0, ...). This scheduling is done in one of the GStreamer
thread, and the display_frame() callback will be called from the main
thread. This can result ..."

Acked-by: Christophe Fergeau <cfergeau at redhat.com>

Christophe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/spice-devel/attachments/20170103/3277e947/attachment.sig>