[vlc-devel] Potential race condition in libvlc_media_player_play

[Hugo Beauzee-Luyssen]

On Thu, Apr 30, 2009 at 5:06 PM, Hugo Beauzee-Luyssen
<beauze.h at gmail.com> wrote:
> Hi,
>
> I'm currently working on VLMC, which uses the libvlc.
> I've recently came across something I think is a bug :
> When I load and play a file (in my test, especially a mpeg file)
> sometimes it fires a libvlc_MediaPlayerPlaying, but sometimes (in most
> of the case actually) it don't.
>
> After reviewing the code, I think the problem is located in the
> libvlc_media_player_play() code :
> basically, the function create an input thread, which will execute the
> Run function, that will call Init, and after a few other calls, it
> finally calls Trigger, which is supposed to call a callback, which is
> set at the end of the media_player_play function ( var_AddCallback(
> p_input_thread, "intf-event", input_event_changed, p_mi ); )
>
> The problem is, in some cases, that callback is set after the Trigger
> function has been called, therefore, the callback is never called, and
> no event is fired.
>
> I'd love to fix this, however I'm not really confident in touching the
> way vlc handles the threads... before doing anything stupid, does
> anyone has any hints on how I could fix this ?
>
> Thanks by advance !
>
> --
> Hugo Beauzée-Luyssen
>

Hi,

After searching for a solution, I don't really see how this could be
achieved without any modification to the way vlc starts the thread...
One of the solution could be to add one parameter to
input_CreateThread, which would be a function pointer. This could
allow the thread creator to specify something different that the Run()
function, which could create the variables and set the appropriate
callbacks before calling Run().
Another solution I tried was to lock a mutex, making the thread wait
until we want it to run. However, every mutex I came across was locked
at least once before the thread was actually spawned...

I feel like trying the first solution, but I don't feel like editing
input_CreateThread, nor input_CreateThreadExtended without prior
positive feedbacks ;)

Regards,


-- 
Hugo Beauzée-Luyssen