[vlc-devel] Another HLS question: vlc_object_alive vs. Close

[Rémi Denis-Courmont]

    Hello,

On Mon, 04 Jun 2012 21:48:16 +0100, Chris Smowton <cs448 at cam.ac.uk> wrote:
> I just fixed an interesting bug in the HTTP live streaming module: when 
> being used via (at least) the QT GUI, it seemed we could rely on getting

> a synchronous kill when the media finished, meaning that by the time 
> Close methods were called vlc_object_alive(...) would return false. 
> However when using the same thing via (at least) the vlcj bindings for 
> libvlc, it wasn't practical to synchronously call vlc_object_kill from 
> within the event handler for media ending because by the time my code 
> gets the event it has already been marshalled across a thread boundary 
> and we've likely returned from the event handler routine.

vlc_object_alive() is totally broken by design and has been flagged as
deprecated for _years_. Adding deprecated functions calls in NEW code like
HTTP live is forbidden.

I think I know who is the reckless incompetent that did it... That would
not be his first time.

> The upshot of all of this is that httplive.c::Close can get called when 
> vlc_object_alive(...) still returns true, and in that situation we 
> vlc_join waiting for a thread that will not die.

Yes. That is to say, vlc_objet_alive() fundamentally broken.

> My fix was simply to add an extra b_closed flag and replace all 
> vlc_object_alive with (!b_closed) && vlc_object_alive, but is that 
> right?

You really should remove vlc_object_alive() altogether. It is a real shame
that some (at least one) irresponsible developers still add it in new code.

Nevertheless b_closed seems just as broken as vlc_object_alive(). You need
a mechanism to reliably wake up the thread. Setting a boolean will not do.

> What are the rules for Close vs. the state of vlc_object_alive? 

There are no rules. vlc_object_alive() should never be used.

> Is it a bug in the bindings not to respond to an EOF with an immediate 
> kill, or should modules be able to deal with that situation?

Uh? Dealing with EOF should not be an issue ever. Usually the more
difficult part is dealing with asynchronous Stop requests from the user.

-- 
Rémi Denis-Courmont
Sent from my collocated server