[vlc-devel] Handling deadlock between display:Open() and vout_window_ReportSize()

[Rémi Denis-Courmont]

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/