Re: gdk threads ...
- From: Michael Meeks <michael meeks suse com>
- To: Stef Walter <stefw gnome org>
- Cc: Ryan Lortie <desrt desrt ca>, Gtk Hackers <gtk-devel-list gnome org>
- Subject: Re: gdk threads ...
- Date: Tue, 22 May 2012 12:03:04 +0100
Hi Stef,
On Tue, 2012-05-22 at 12:19 +0200, Stef Walter wrote:
> On 05/21/2012 04:18 PM, Paul Davis wrote:
> > > That claim sounds really strange; since - well - we do that in
> > > LibreOffice ourselves :-)
...
> Michael, it may just happen that the GTK calls you've seen being
> performed from arbitrary threads in LibreOffice don't result in Win32
Wait - we're not using gtk+ on windows :-) we are using our own native
VCL toolkit. I'm well aware of the windows constrains on message
handling, and thread affinity of some subset of the API.
> 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 ;-)
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.
ATB,
Michael.
--
michael meeks suse com <><, Pseudo Engineer, itinerant idiot
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]