[ruby-talk:10748] Re: Threading model change, proposal

In article <[e-mail]>,
Ben Tilly <[e-mail]> wrote:
>Andrew Kuchling <[e-mail]> wrote:
>>
>>"Ben Tilly" <[e-mail]> 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:
>[...]
>>So most GUI toolkits impose their own serialization, apparently
>>similar to having a global lock.
>
>I think we are talking past each other.  It makes perfect
>sense for the GUI toolkit to serialize various internal
>operations.  However what is frustrating is to (for
>instance) push a button that launches a possibly long
>database request in the background and then have your
>screen freeze.  Or to be unable to break off a web page
>request.
>
>Multi-threading with real threads is valuable, and can
>work just fine even if only one thread talks to the GUI.
			.
			.
			.
There *is* a lot going on in this thread.  I agree
with both Andrew and Ben, each of whom has made several
valuable points.

In real-world development practice, having only "one
thread talk to the GUI" is nearly universal.  I can't
think of any good reason to have more.  I'm keeping an
open mind on this one, though.

Along with the categories Andrew listed, there are a few
other reasons to use threads:
1.  Fashion and misinformation.  There are a
    lot of people who sincerely believe they
    need to or should use threads, just be-
    cause ... well, someone said so.
2.  System-level bindings that only give good
    programmability for threaded APIs.
3.  Mildly tangled with the first two, Ben's
    cases of external stuff that demands thread-
    level management.  He rightly described
    a long-running database query.  A *good*
    interface will have an asynchronous API, but
    a lot of the interfaces we all deal with
    aren't good ones.

    A counter to this that occasionally helps is
    that, if it really is a long-running execu-
    tion context that's external to the body of
    the application, it can just as well be in its
    own process as its own thread.  At that point,
    pre-emptive scheduling becomes easier again.
-- 

Cameron Laird <[e-mail]>
Business:  http://www.Phaseit.net
Personal:  http://starbase.neosoft.com/~claird/home.html