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

[Chris Smowton]

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.