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

[Rémi Denis-Courmont]

Once more, set the EOF flag in the block callback.

-- 
Rémi Denis-Courmont
Sent from my NVIDIA Tegra-powered device

----- Reply message -----
De : "Romain Vimont" <rom at rom1v.com>
Pour : "Mailing list for VLC media player developers" <vlc-devel at videolan.org>
Objet : [vlc-devel] [PATCH] Avoid deadlock on UDP stop
Date : mer., mai 21, 2014 17:58

The problem is not to set b_eof. The line:

p_access->info.b_eof = true;

is secondary. Indeed, while it is necessary to avoid BlockUDP() to be
called again and again indefinitely once block_FifoGet() does not
deadlock anymore (with the remaining of the patch), it does nothing to
prevent the deadlock itself.

The main point is the call to "return NULL" when we know that
ThreadRead() is complete (i.e. it will not feed the fifo queue anymore,
i.e. b_finishing is set), preventing to call block_FifoGet().

Anyway, when would you write b_eof? On what condition, apart from
b_finishing?

--
®om

Le mercredi 21 mai 2014 à 17:33 +0800, Rémi Denis-Courmont a écrit :
> Le 2014-05-21 16:53, Romain Vimont a écrit :
> >This is not a problem because I don't use b_eof for that. If I would
> >write it from TR, then it would be a problem…
> >
> >According to you, apart from using a (synchronized) flag like
> >b_finishing, how should we make TR wake up BU (blocked in
> >block_FifoGet() in BlockUDP()) from the end of ThreadRead(), in order to
> >prevent the deadlock in all cases?
> 
> Write b_eof from BlockUDP() as normal, IIRC it was mentioned already.
> 
> Or better yet fix the real problem, the multiple unsynchronized alive flags
> of the input objects.
> 
> -- 
> Rémi Denis-Courmont
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> https://mailman.videolan.org/listinfo/vlc-devel
_______________________________________________
vlc-devel mailing list
To unsubscribe or modify your subscription options:
https://mailman.videolan.org/listinfo/vlc-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20140521/bd8b1696/attachment.html>