[vlc-devel] Another HLS question: vlc_object_alive vs. Close
Chris Smowton
cs448 at cam.ac.uk
Wed Jun 6 16:07:58 CEST 2012
On 05/06/12 16:55, Chris Smowton wrote:
>
>> Open(), Read(), Peek() and Close() are serialized. If Read() gets
>> stuck, Close() cannot be called, and the whole input thread will
>> deadlock.
> Aha, so the only way to spot an asynchronous
> libvlc_media_player_stop() is by way of its two consequences: setting
> p_object->b_die and signalling a waitpipe if one exists (and ensuring
> that future waitpipes are immediately signalled).
>
> Obviously aborting I/O operations should be achieved by selecting on
> both the waitpipe and the target FD, and long sleeps can be
> interrupted by using a timed select instead. What about ongoing
> computation though? To give an HLS example, it would be useful to know
> whether the object is signalled so the download thread can tell the
> difference between failure because we got signalled and failure
> because of a network problem. The obvious way would be to check b_die
> before we continue (and it doesn't matter if we race as any future
> attempted downloads will fail immediately because we're signalled),
> but that's equivalent to vlc_object_alive! I could poll a waitpipe but
> that's pointless and still equivalent to vlc_object_alive. What is the
> right thing to do in this situation?
So I had a go at rewriting this to avoid using object_alive, but found
it impossible with the current asynchronous shutdown mechanism. The
problem is when shutdown requests happen between one segment download
and the next; in this case the fresh access_http which is created to
conduct the second download doesn't inherit the waitpipe status of its
parent, and as a result it succeeds, potentially taking a long time to
do so. What's needed is either (a) a custom interrupt callback, like
that which is called from vlc_object_destroy, allowing me to notify the
download thread appropriately, or (b) access to the waitpipe function
from modules, though this latter would be ugly as I'd have to run a
dedicated thread that just watches the waitpipe and repeats that in a
different form.
More information about the vlc-devel
mailing list