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

[Rémi Denis-Courmont]

On Tue, 05 Jun 2012 10:36:06 +0100, Chris Smowton <cs448 at cam.ac.uk> wrote:
>>> 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.
> That's not what I meant. I meant, are all situations when I should die 
> heralded by a Close call, or are there other asynchronous abort signals 
> that I should be watching?

Close() is called whenever the stream reader (usually an instance of a
demux plugin) is done with reading the stream.

Why does this happen is none of your business; the principle of
encapsulation applies. The most typical causes are user-requested stop, end
of stream or fatal error in the demuxer while parsing the byte stream.

>>> 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.
> That's not what I meant either. I meant, suppose I am currently waiting 
> inside Read or something like that when the user hits stop. Will I get a

> Close call at that time, or will it only get called after Read returns 
> (e.g. because the same thread is responsible for both calls, or there's 
> a convention of interlocking module entry points, or...)

No. Open(), Read(), Peek() and Close() are serialized. If Read() gets
stuck, Close() cannot be called, and the whole input thread will deadlock.

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