Re: I lose in threads + GTK+, looking for help

["Freddie Unpenstein" <fredderic excite com>]

> > > You can't use GTK+ from multiple threads on Win32.
> > Can you give some more details Tor? I've done it, so then maybe
> > my program is buggy and I don't know it yet :)
> Search the list archives, this has been discussed several times ;)
> Or are you actually just scheduling stuff to be executed in the main
> thread from the other threads by using g_idle_add() etc?

I wonder how hard it would be to write a generic internal "thread" IPC-type mechanism?  A way to efficiently 
package a function pointer and set of arguments, perhaps in a thin GObject using GValue's, drop it into an 
AsyncQueue-based "IPCQueue" set up by the IPC mechanism, and wait for it to happen.

Only hard part as I see it is wrapping the API functions.  You'd want a local wrapper to keep the argument 
types straight (though they could be written by an application as-needed, and wouldn't be needed at all if 
they're only called from one or two places), and a marshaller at the other end to call the target function, 
and (optionally) collect the return value.  Sounds like it would be an extreamly good addition to the GLib 
API's, considering how frequently this issue arises.

Being thread-based, all sorts of shortcuts could be taken, but it may even be possible to stretch such a 
thing across full process boundaries for supporting applet-style plugins (a queue serialiser or something 
could also add some filtering, as it translates function names into the function pointers).

But best of all, with most objects making exhaustive use of properties, a great chunk of the API should be 
wrapped up quite easily through a few convenience functions, and likewise for establishing signal callbacks 
and so forth.

Possible?


Fredderic

_______________________________________________
Join Excite! - http://www.excite.com
The most personalized portal on the Web!