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

[Thomas Guillem]

On Mon, Sep 3, 2018, at 09:53, Thomas Guillem wrote:
> 
> 
> 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.

Typo: It *can*

> 
> 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
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> https://mailman.videolan.org/listinfo/vlc-devel