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

Rémi Denis-Courmont remi at remlab.net
Tue Jun 5 11:52:29 CEST 2012

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

More information about the vlc-devel mailing list