Re: gdk threads ...

[Paul Davis <paul linuxaudiosystems com>]

On Mon, May 21, 2012 at 9:39 AM, Michael Meeks <michael meeks suse com> wrote:

> your code is designed around the execution of GDK/GTK code in multiple
> threads. it was unfortunate that GDK/GTK ever allowed this (as has
> been pointed out, this is absolutely NOT possible on Windows with
> violating several fundamental parts of the Windows API).

       That claim sounds really strange; since - well - we do that in
LibreOffice ourselves :-)

Windows does not allow you to process events/messages for a given window in anything other than the thread that created the window. If you try to do this, you will either crash or cause memory corruption.

operations to execute in the right place, that is for sure. However
doing this in the toolkit requires that work to be done once, in one
place for all users.

its certainly not provided for in the windows API, unless you mean SendMessage which I hardly think counts :) I also happen to think that return values from a cross-thread call to the GUI thread is another indication of a design that needs rethinking. i'm not trying to tell you that i think libre office should be rewritten to match my ideas - just noting that its hard for a toolkit to put much effort into support design ideas if (and i do mean if) there's a growing sense that the ideas are just wrong.

if the ohloh comparison is of any use, the key part of the ohloh comparison might be this:
                                                   
                                                   Libre Office        Ardour
    Committers (Past 12 Months) 312 developers 7 developers
    Committers (Past 30 Days)       80 committers 4 committers
 
if we can write our own replacement for boost::signals2 when we find out thats its lazy cleanup is incompatible with our thread semantics, then with more than 4 times as many committers, i would guess you can figure out how stop calling GDK/GTK functions from the wrong threads :)