[vlc-devel] [V1 PATCH] RFC: add vlc_player_t (input manager)

[Thomas Guillem]

On Sat, Sep 1, 2018, at 11:11, Rémi Denis-Courmont wrote:
> Le perjantaina 31. elokuuta 2018, 18.53.07 EEST Thomas Guillem a écrit :
> > All controls of the player are asynchronous, even vlc_player_Stop(). I saw
> > too many hacks in VLC ports for stopping the player, they generally spawn a
> > detached thread that will stop it.
> 
> There should be a way to request stop without blocking the UI thread, in other 
> words without actually waiting for stop. You can add an asynchronous 
> libvlc_media_player_stop_request() if you want.

In that case, is the the next start delayed until the stop is done ? I guess yes.

> 
> But the application will still need to wait eventually, not only when it 
> destroys the player, but also if it changes player settings or backing 
> resources. If it creates a detached thread to side step the issue, the 
> application is broken, and LibVLC is not in a position to fix it.
> 
> Designing for broken-by-design applications does not strike me as a good idea.
> 
> > Indeed, input_Close() is blocking, it
> > wait for the input thread to be terminated. This should be instantaneous
> > for basic remote accesses that handle vlc_interrupt. But what do we do for
> > remote accesses that need a teardown of local accesses (yes, it's really
> > easy to block on a USB drive) ?
> 
> We wait because the next input might contend for the same resources as the 
> current one, and thus needs to be opened after the current one is closed.
> 
> The case of a stuck filesystem is not something you can fix in VLC. It is an 
> OS issue that your application can do literally nothing about.

I know that, that's why I proposed the asynchronous stop.

> 
> Currently, the playlist thread waits between inputs, and going forward the 
> input manager will still have to strictly sequence input threads. Otherwise, 
> there will be no ends of use-after-free, resource contention and/or other race 
> condition bugs.

Good point

> 
> > My proposal is the destructor struct from player.c. When the user need to
> > stop a playback, the player will prevent input events forwarding, call
> > input_Stop() and won't wait for the input thread termination. Instead, when
> > the INPUT_EVENT_DEAD event will be received, the input_thread_t instance
> > will be passed to the destructor thread that will join it.
> 
> libvlc_media_player_stop() has to wait for stop to complete, since that is the 
> documented and only supported way to release underlying media player resources 
> in orderly fashion. So there must be a way to support 
> libvlc_media_player_stop() releasing resources without destroying the media 
> player.

libvlc_media_player can't play several medias, and chain start/stop. That's what I want to do for the code player too.

To sum up, I'll add vlc_player_StopAsync().
I guess that the next Start (that is always asynchronous) will wait for the stop to finish.

> 
> -- 
> Реми Дёни-Курмон
> http://www.remlab.net/
> 
> 
> 
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> https://mailman.videolan.org/listinfo/vlc-devel