[vlc-devel] Another HLS question: vlc_object_alive vs. Close
Chris Smowton
cs448 at cam.ac.uk
Tue Jun 5 17:55:38 CEST 2012
> 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?
Chris
More information about the vlc-devel
mailing list