LibVLC: media_player Possible deadlocks when using external locks
cf. discussion with @alexandre-janniaux here: !4915 (comment 426084)
!4915 (closed) is not introducing the issue, we already have few events that are sent directly from `vlc_player` functions. In that case, there will be an issue when:
1. libvlc application hold its own lock
2. libvlc application calls a libvlc_media_player function
3. It trigger an send directly or indirectly from that function
4. libvlc application try to hold its own lock from the callback
=> DEADLOCK
Here is a possible to way this behavior:
- Some events can be moved from the
vlc_player
to theinput_thread
thread. - Few events (not related to
input_thread
can be sent to thedestructor
thread (that need to be renamed) to be sent asynchronously - Some
input_thread
are sent synchronously (cf.input_SetEsCatDelay
) => All controls should be executed from theMainloop