[vlc-devel] Handling deadlock between display:Open() and vout_window_ReportSize()
ajanni at videolabs.io
Sun Dec 15 13:17:11 CET 2019
On Sun, Dec 15, 2019 at 02:06:08PM +0200, Rémi Denis-Courmont wrote:
> 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.
These three cases are with my changes, like I wrote.
I understand that this third case is impossible otherwise
because it's the core of my issue.
Is there a special reason why it should stay like that
instead of an acknownledgement design or an alternative one?
More information about the vlc-devel