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@xxxxxxxxxx> Christophe
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/spice-devel