[vlc-devel] Handling deadlock between display:Open() and vout_window_ReportSize()

Rémi Denis-Courmont remi at remlab.net
Sun Dec 15 13:06:08 CET 2019

Le sunnuntaina 15. joulukuuta 2019, 13.53.36 EET Alexandre Janniaux a écrit :
> Hi,
> On Sun, Dec 15, 2019 at 01:37:24PM +0200, Rémi Denis-Courmont wrote:
> > Le sunnuntaina 15. joulukuuta 2019, 13.20.43 EET Alexandre Janniaux a 
écrit :
> > > Hi,
> > > 
> > > After some thoughs, surveys of locks and schematics I might
> > > have a solution for allowing the vout_display::Open to block
> > > the main thread without additional lock.
> > > 
> > > It seems that I can just move the display creation outside of
> > > the display_lock, and then lock it to share it with sys while
> > > applying the pending requested state after the Open() has
> > > ended, so that the behaviour stays the same.
> > 
> > That breaks the lock chaining which ensures that the configuration stays
> > in in synchronization in the window, display and core.
> Isn't it a false synchronization, if you have a race between
> display open and resize? With this change you would have
> either:

There's no race. Currently, the size change is held off by the creation of the 
display. That's the whole point of having synchronous size changes.

> + the display is created before the resize, the resize will
>   update display size through control.
> + the display is created after the resize, the configuration
>   is correct from the beginning.
> + the display is created at the same time as the resize, it
>   opens with the previous configuration and will get a resize
>   control in the display lock right after it opened. Same for
>   other state changes.

The third case is impossible. Whoever wins the display lock gets to happen 
before the other, which guarantees that the display and window agree on the 
size at all times. Again, that's the whole point.

Реми Дёни-Курмон

More information about the vlc-devel mailing list