[573] in The GTK GIMP ToolKit mailing list archive
[gtk-list] Making gtk thread-safe
daemon@ATHENA.MIT.EDU (Elliot Lee)
Tue Jul 29 17:27:15 1997
Date: Tue, 29 Jul 1997 17:25:33 -0400 (EDT)
From: Elliot Lee <sopwith@redhat.com>
To: gtk-list@redhat.com
Resent-From: gtk-list@redhat.com
Reply-To: gtk-list@redhat.com
I've been thinking about making gtk thread safe. It seems like it is
becoming an often-requested feature. Here are some random thoughts of mine
on the issue:
The easiest way to do this is the global mutex. This doesn't help
performance very much, though.
We could possibly make a gtk_app_state structure that is created by
gtk_init_r() [the present gtk_init() would just initialize a global
default_appstate variable with the return value of gtk_init_r()] and have
a particular app_state associated with each gtk_object. Having an
gtk_app_state structure would also allow gtk programs to use multiple
displays, another handy feature.
Only problem is having to change all the gtk_*_new() routines to allow
passing in a gtk_app_state, perhaps changing all the gtk_*_new() routines
to be gtk_*_new_r() and then replacing the gtk_*_new() routines with ones
that just call the _r() routine with default_appstate.
Is the present lack of thread safeness due to global variables, routine
non-reentrancy, or what? Obviously having two threads manipulating the
same widget at the same time could be hazardous, so per-object locking
could be done in addition to some locking ot the gtk_app_state structure
in question.
Tell me I'm loony, tell me I'm wonderful, just tell me :-)
-- Elliot http://www.redhat.com/
What's nice about GUI is that you see what you manipulate.
What's bad about GUI is that you can only manipulate what you see.
--
To unsubscribe: mail -s unsubscribe gtk-list-request@redhat.com < /dev/null
