[vlc-devel] [RFC] design issue related to resources (input)

[brezhoneg1]

                Hello,

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


_Wider Reflection_

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


Since some work is currently being done in this matter,  I hope this 
email can be of any help..

Regards
Erwan10





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20100603/aadd2e0e/attachment.html>