Re: gdk threads ...

[Stef Walter <stefw gnome org>]

On 05/22/2012 01:03 PM, Michael Meeks wrote:
>> Even if you get the locking "right" -- even if absolutely only one
>> thread is executing at once in your process -- like Paul said, you still
>> get behavior that at a minimum freezes your window, and in other cases
>> can act a lot like memory corruption.
> 
> 	Sure I can believe gtk+ is broken currently in this regard. However my
> contention is that this is not an inevitable problem for gtk+ caused by
> the windows API. It is -possible- to get the gtk+ model to work, well,
> on windows. VCL does it today with a very similar locking model to the
> one gtk+ has used (again without using gtk+). I would also point out
> that VCL is not a top-flight, well-maintained, documented, high-quality
> toolkit with dozens of people working on it either ;-)

If you have more details/links on how VCL gets around this, I'd be
interested. A bit of a morbid curiosity perhaps :P

Perhaps VCL isn't generic enough to run into this problem? Or is it
solved by handing off all OS window creation in the main thread? Or
running multiple windows message loops, and passing off received data to
a main loop in another thread? Or perhaps it's just by chance that the
problem hasn't been encountered during regular usage patterns?

Seems like these would be pretty hacky solution for a general purpose
toolkit like GTK+ to do. Or has VCL found a more correct solution to the
problem? Again, asking out of interest here, as this has been a big
obstacle for me several times over the years.

> 	So the "it is fundamentally impossible to do" argument seems just a bit
> weak from my perspective, I read it as "it is easier not to do, and it's
> better to make our API users do the work instead" ;-) which is rather
> different. 

Right, obviously not fundamentally impossible (given Turing completeness
and all that) ... the issue is whether it's possible to do in a general
purpose and correct way.

Cheers,

Stef