From: claird@... (Cameron Laird) Date: 2001-02-13T06:10:02+09:00 Subject: [ruby-talk:10748] Re: Threading model change, proposal In article , Ben Tilly wrote: >Andrew Kuchling wrote: >> >>"Ben Tilly" 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 Business: http://www.Phaseit.net Personal: http://starbase.neosoft.com/~claird/home.html