From: Andrew Kuchling <akuchlin@...>
Date: 2001-02-13T03:10:03+09:00
Subject: [ruby-talk:10736] Re: Threading model change, proposal

"Ben Tilly" <ben_tilly@hotmail.com> writes:
> I suspect that the most common appliation for threading is
> to allow a GUI to be responsive even when the program is
> busy doing something else.

But note that most GUI toolkits implement an event loop internally,
and CPU-heavy computations needs to take this into account in order to
work smoothly.  Having a fine-threaded scripting language won't help
if your GUI has a global lock of its own.  Quoting from documentation
for various toolkits:

GTk+: http://www.gtk.org/faq/#AEN473

        The GLib library can be used in a thread-safe mode by calling
        g_thread_init() before making any other GLib calls. In this
        mode GLib automatically locks all internal data structures as
        needed. This does not mean that two threads can simultaneously
        access, for example, a single hash table, but they can access
        two different hash tables simultaneously. If two different
        threads need to access the same hash table, the application is
        responsible for locking itself.

        When GLib is intialized to be thread-safe, GTK+ is thread
        aware. There is a single global lock that you must acquire
        with gdk_threads_enter() before making any GDK calls, and
        release with gdk_threads_leave() afterwards.

Qt: http://doc.trolltech.com/threads.html

        In version 2.2, Qt introduced thread support to Qt in the
        shape of some basic platform-independent threading classes, a
        thread-safe way of posting events and a global Qt library lock
        that allows you to call Qt methods from different threads. 
        
        ... 

        Calling a function in Qt without holding a mutex will
        generally result in unpredictable behavior. Calling a
        GUI-related function in Qt from a different thread requires
        holding the Qt library mutex.

Tcl -- I can't find anything specific on Tk itself, but assuming this
description of Tcl is still correct, I can't see how Tk could be more
flexible than Tcl: http://dev.scriptics.com/doc/howto/thread_model.html

        Tcl lets you have one or more Tcl interpreters (e.g., created
        with Tcl_CreateInterp()) in each operating system thread.
        However, each interpreter is tightly bound to its OS thread
        and errors will occur if you let more than one thread call
        into the same interpreter (e.g., with Tcl_Eval).

So most GUI toolkits impose their own serialization, apparently
similar to having a global lock.  

--amk