Re: [client] streaming: Fix a race condition in the GStreamer frame display queue

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

I've now pushed this patch with the amended log, hopefully it was
correct ;)

Christophe

On Tue, Jan 03, 2017 at 10:56:49AM +0100, Christophe Fergeau wrote:
> 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



> _______________________________________________
> Spice-devel mailing list
> Spice-devel@xxxxxxxxxxxxxxxxxxxxx
> https://lists.freedesktop.org/mailman/listinfo/spice-devel

Attachment: signature.asc
Description: PGP signature

_______________________________________________
Spice-devel mailing list
Spice-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/spice-devel

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]     [Monitors]