[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 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

I meant a good point for the fist sentence of this paragraph.
But they won't be any use-after-free and I don't the possible race conditions here.

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