Re: thread support in Windows: problem

["fkater googlemail com" <fkater googlemail com>]

On 23:55 Thu 24 Jan     , Tor Lillqvist wrote:
> > Write wrapper functions for any gtk operation you'd like to execute from
> > threads in a way that the thread calls a glib's idle function which does
> > the real gtk work.
>
> An interesting approach. Did you use some automated technique to
> generate these wrappers, or just manual work?

It is not automated in the sense of having implemented it into gtk
directly. However, I've made a library which of course sets up an 
architecture with wrappers and callback tables which in turn makes 
it easier to integrate those gtk widgets I personally had no need for 
yet.


> How well does it work and how general is it?

I believe it works well, I've coded an app with several windows, a tree
like selection and some 50 complex user interfaces created and deleted
on the fly by selecting items from the tree.

This app starts algorithms in the background as threads. They all may
change widgets simultaneously (like log window entries, displaying images 
or simply change counters etc.).

And it is portable on win32 and linux.


> Do you think it would be
> generally useful for other people, or is it just for your own specific
> need?

Hm, from what I read in the mailing lists there seems to be some need to
push gtk a bit from the thread-awareness towards the thread-safety.

> Are you interested in making your stuff available for others
> (and maintain it in the future...)?

I'd like to spend some spare time to offer my experience, and the code,
too, but I've got to talk to my boss if that is o.k. And there would be 
the need to separate this library from my win32/linux thread wrapper 
and keying (handle) system.

Do you think it would help to first simply create a draft of the concept 
as a pdf or so for download ?

Are there already plans to make gtk thread-safe (or reasons not to do
so) ?

As I mentioned it was necessary to wrap even the widgets itself to access 
their values immediatedly rather than bothering gtk and wait for the 
return of idle functions. So, the library IS something like a layer on 
top of gtk rather than something to be easily implemented into gtk. Would 
it make sense to you to continue this way ?

Felix