[vlc-devel] [PATCH] Avoid deadlock on UDP stop

Rémi Denis-Courmont remi at remlab.net
Thu May 22 12:27:04 CEST 2014

Le 2014-05-22 18:00, Romain Vimont a écrit :
> However, (B ==> A) is false:
>   By definition, we consider that we reach EOF once ThreadRead() 
> cannot
>   put more blocks into to fifo queue anymore, i.e. once it calls
>   block_FifoWake().

By definition, an UDP stream *never* reaches EOF. Setting EOF because 
the user requested to stop is already a nasty kludge.

>   The semantic of block_FifoWake() is to make
>   exactly one call to block_FifoGet() nonblocking. During that call, 
> the
>   fifo may not be empty (i.e. p_fifo->p_first != NULL). In that case, 
> it
>   does not return NULL (and p_fifo->b_force_wake will remain unset).

By that line of reasoning, it is wrong to set EOF at all anyway. The 
stream did not end. The user asked to stop reception.

> Therefore, setting b_eof when block_FifoGet() returns NULL is not
> sufficient, it would not fix the deadlock.

It will not fix the deadlock and your patch does not fix the alleged 
deadlock either. Your patch is a kludge because not only it works around 
the alleged bug rather than fix it, but it abuses the EOF flag.

> Instead, the command should be either "do not retrieve any block
> anymore" (what this patch implements), or "retrieve pending blocks, 
> but
> stop (do not block) once the queue is empty".

We already have an atomic variable for the purpose of detecting the 
user stop. I refuse to add another one. Is it that difficult to grasp a 

> I consider this as a root cause in itself.

We are going to have to disagree then.

If net_Read() failed, then there should not even be no more calls to 
pf_block anyway. So either your alleged bug is non-existent or something 
is wrong *outside* the UDP access.

Rémi Denis-Courmont

More information about the vlc-devel mailing list