Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!tut.cis.ohio-state.edu!ucbvax!EXPO.LCS.MIT.EDU!rws
From: rws@EXPO.LCS.MIT.EDU (Bob Scheifler)
Newsgroups: comp.windows.news
Subject: Re: event-driven applications
Message-ID: <9001031356.AA01664@expire.lcs.mit.edu>
Date: 4 Jan 90 19:34:44 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 15


    Like, say you want a program to go away for a while and do some work.
    Under X you lose the UI... and you can't even put up an "I'm busy" sign
    because it won't get displayed until you return to the event loop.

Another over-generalization that seems typical for this list.  "X" is a whole
lotta things these days.  To claim that all instances of X applications are
single-threaded and strictly event-driven, in the canonical manner of Xt, is
rather silly.  There are multiple researchers out there working with X on
the client side in a multi-threaded environment; there are even one or two
products that work this way.  Whether a multi-threaded client environment is
better or worse than a single-threaded client with multi-threaded server is
rather debateable, I'd say.  The design of Xt was a concious one, for its
portability across a wide range of systems.  Clearly the model isn't adequate
for all applications; that's good, it was an engineering solution.