[vlc-devel] [PATCH v2 2/4] macosx: wait until the View is removed from its parent in Close

Alexandre Janniaux ajanni at videolabs.io
Tue Nov 3 13:20:26 CET 2020


Hi
On Tue, Nov 03, 2020 at 12:58:38PM +0100, Marvin Scholz wrote:
> > > > > > +- (void)waitRemoved:
> > > > > > +{
> > > > > > +    vlc_sem_wait(&removed);
> > > > > > +}
> > > > > > +
> > > > >
> > > > > Won't this deadlock, just like using a dispatch sync would
> > > > > deadlock?
> > > > > As during close vlc blocks the main thread waiting for the
> > > > > Close to finish,
> > > >
> > > > How would it block the main (UI) thread ?
> > >
> > > How would it not block the UI thread?
> > > On close you dispatch to the main thread to detach the view while
> > > the core is blocking on the main thread.
> >
> > Are you talking about close from the GUI or the Close callback called
> > from the core ? I am talking about the latter. The core waits on
> > display_lock, not the main/UI/GUI thread.
> >
> > It would wait with this patch, but the removeSubview is not supposed to
> > do anything involving the core (or display_lock). It does however if
> > there are pending display_lock waiting in the UI thread. There is the
> > deadlock.
> >
>
> I am talking about close callback called from core. You can not wait on
> actions happening on the main
> thread in the close callback.
>
> This is not about the display lock but about libVLC blocking the main thread
> when its stopping and
> Closing the vout. So when you wait for an async dispatch happening on the
> main thread you will just
> wait forever on this as it can never happen, because the main thread is
> blocked.

And in general, you don't even have to since you won't need to
return a result and NSObject-s are refcounted.

Regards,
--
Alexandre Janniaux
Videolabs


More information about the vlc-devel mailing list