[vlc-devel] Handling deadlock between display:Open() and vout_window_ReportSize()
Rémi Denis-Courmont
remi at remlab.net
Mon Dec 16 19:43:59 CET 2019
Le maanantaina 16. joulukuuta 2019, 10.50.39 EET Alexandre Janniaux a écrit :
> Hi,
>
> On Sun, Dec 15, 2019 at 08:55:03PM +0200, Rémi Denis-Courmont wrote:
> > Le sunnuntaina 15. joulukuuta 2019, 19.05.15 EET Alexandre Janniaux a
écrit :
> > > Ok, I'll try to find another model matching the current
> > > intents of the code and my use case.
> >
> > I don't even get why you want to mess the core.
>
> I don't think I'm messing anything,
I call adding a useless lock and a data race messing.
> and neither that this is polite
I don't think somebody who solicits comments then rejects them under the false
pretense that it was not even a patch, and berates the reviewer, should be
complaining about politeness.
> to tell think like this politely especially given that
> I didn't send any patch yet.
I do see a patch in unified diff format in the first post of this thread, in a
mailing list that is called vlc-devel. Even the defacto standard extension for
that file format is literally "patch".
Bad faith much?
> The caca.c output is not windowed, and the thread that you're
> mentioning seems to be sending events during the lifetime of
> the vout, meaning after Open() as blocks are pushed in
> Prepare. Can you explain how it can be applied here?
I already did:
"If you don't want events to block, you can send them from a thread like the
ASCII Art output already does."
You can't have it both ways. You can't both have blocking/synchronous events
from, and send blocking/synchronous requests to, the same thread. That will
always deadlock by definition.
--
雷米‧德尼-库尔蒙
http://www.remlab.net/
More information about the vlc-devel
mailing list