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

[Romain Vimont]

The block callback *is* BlockUDP() and I set b_eof in BlockUDP(), so
that's exactly what I do.

But you suggested (here and on irc) that I should not do anything more.
I think this is both incomplete and insufficient:
 - incomplete: on what condition do you set b_eof?
 - insufficient: how could that resolve the deadlock?

--
®om

Le mercredi 21 mai 2014 à 18:58 +0800, Rémi Denis-Courmont a écrit :
> 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

> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> https://mailman.videolan.org/listinfo/vlc-devel