[vlc-devel] [RFC] design issue related to resources (input)
brezhoneg1 at yahoo.fr
Thu Jun 3 14:00:31 CEST 2010
Recent change in git master have brought a regression with skins2, that
may point out a deeper design issue and wider questions.
_Test case for regression_
- start 'vlc -I skins --no-video'
- play an item
- quit vlc (while playing is underway)
vlc then crashes in input_resource_HoldAout with :
/LibVLC fatal error locking mutex (22) in thread 29236 at
misc/pthread.c:223 in vlc_mutex_lock/
which means that we try to use an already deallocated mutex (the
lock_hold for resource)
Note that --no-video is important in this test case. Otherwise, resource
seems to be kept accessible longer, and no crash occurs.
_Cause for the problem
Actually, during playlist deactivation, the current input thread is
joined, the input object is released and resource is deallocated. Yet,
the input object is still held by some other parts of vlc (the skins2
interface and the qt4 dialog provider) , and resource is a key part of
the input object for input_GetAout, input_GetVout, .... helper functions
to succeed. As long as an input is not truly deallocated, resources
should be accessible, since we need them to remove callbacks on aout/vout
From the perspective of an interface developer, the vlc core may be a
bit complicated. We need to retrieve the playlist object, then
successive inputs, then aout or vout to add callbacks on all of them.
Since aout/vout reuse, it is even trickier in a sense that not all
variables are reset on a per input basis (see the audio equalizer). I
always wondered why a single object (playlist, media player for libvlc
or vlm manager) would not host all exported variables worth of interest
for interface. Actually, aout/vout or successive inputs for a playlist
should be kept as an internal implementation, not something interface
developers must be aware of. Because of all these different objects,
interfaces need to retain references or retrieve them with input_GetAout
.... to properly remove callbacks. That may actually conflict with the
way vlc core wishes to deallocate things. If interfaces were to handle
only a single object, then all the complexity would be mutualized in a
single place (at vlc core), instead of in all interfaces (qt4, skins,
....). This single object (playlist, media player, vlm manager) could be
just a proxy for the already existing input/aout/vout objects and
Since some work is currently being done in this matter, I hope this
email can be of any help..
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the vlc-devel