[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