[386] in The GTK GIMP ToolKit mailing list archive
[gtk-list] Re: gtk and LinuxThreads
daemon@ATHENA.MIT.EDU (Owen Taylor)
Mon Jun 23 22:08:06 1997
To: gtk-list@redhat.com
From: Owen Taylor <owt1@cornell.edu>
Date: 23 Jun 1997 22:08:49 -0400
In-Reply-To: Niku Kaitaniemi's message of Tue, 24 Jun 1997 02:07:14 +0300 (EET DST)
Resent-From: gtk-list@redhat.com
Reply-To: gtk-list@redhat.com
Here's something I said a couple of months ago about the issue. I
think it's still reasonably correct, though I'm not much of an expert
in an area. (I haven't even looked at how other libraries handle thread
safety). I just installed glibc-2.0 with LinuxThreads the other day,
so maybe I'll look at it sometime. Maybe.
Regards,
Owen
[ question was asked about whether gtk was thread safe, I responded: ]
> It's an interesting question. I think the simple answer is no, gtk
> is nowhere close to thread safe. Putting a big lock around the whole
> library would be pretty damn tedious since gtk/gdk has approximately
> 780 entry points. If you were willing to guarantee that two threads
> would never access widgets under the same toplevel, it wouldn't be too
> hard to lock the global data correctly (I think). If you just ensured
> that two threads never accessed the same widget, you'd have to do some
> hacking on the resizing code (which is pretty complicated), but its
> probably a doable project.
> On the other hand, in your case I would just confine all the code
> that interacts with gtk to a single thread. Have the computational
> thread write its data into a buffer and set a flag, and have
> the interface thread check the flag in a timeout and redraw when
> necessary.
--
To unsubscribe: mail -s unsubscribe gtk-list-request@redhat.com < /dev/null
