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

[Alexandre Janniaux]

Hi,

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?

Regards,
--
A