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

[Chris Smowton]

>> 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.
Sure, it was actually a boolean guarded by the download thread's mutex / 
CV pair. It will reliably stop the download and update threads, so it 
can replace both of those obj-alive calls. However...
>> 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.
Indeed, but clean EOF was the case that broke HLS. It doesn't break for 
the QT GUI because it synchronously calls kill-object when it hears the 
state go from Playing to EOF.

Two other questions to properly fix this, then I'll submit a cleanup patch:

1. Can I always rely upon getting a Close call in the situations when 
the existing code is using obj-alive to determine if we should die?

2. Relatedly, can Close be legally invoked whilst we're inside another 
module callback (Open or Control)?

If the answer to 2 is no then I guess obj-alive would be needed to spot 
when we should abort a blocked read, for example?

C