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

[Rémi Denis-Courmont]

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.

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.

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.

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

-- 
Реми Дёни-Курмон
http://www.remlab.net/