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

[Rémi Denis-Courmont]

On Tue, 05 Jun 2012 10:13:45 +0100, Chris Smowton <cs448 at cam.ac.uk> wrote:
> 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...

OK, good.

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

Hmm? That sounds like some cargo cult programming.

On EOF, just make sure the pf_read function returns EOF to the caller,
i.e. the demux. The demux shall then return EOF to the input thread. Then
everything will be cleaned up and the next playlist item will start or
whatever.

> 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?

Do not use object alive. It does not warrant anything other than ->b_die
was set.

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

There is no answer here. A plugin can always call its own functions if
said functions are adequately written. For instance, many plugins call
Close() from Open() on their error paths.

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