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

[Laurent Aimar]

Hi,

On Thu, Jun 03, 2010 at 02:00:31PM +0200, brezhoneg1 wrote:
> 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.
 I will quickly fix this issue. Thanks for the report.

> 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.
 I do aggree that an input manager should be implemented. But it's a lot of work
with some tricky parts (like multiple vout/aout supports, configurations, API...).
 I am not interested to work on it for the moment. Dunno if someone feels up to the
task, knows the core and requirements and is motivated enough.

-- 
fenrir