Why so little parallelism?
|
From: Nick Maclaren on 22 Dec 2006 06:55 In article <1166787244.167779.152770(a)h40g2000cwb.googlegroups.com>, "ranjit_mathews(a)yahoo.com" <ranjit_mathews(a)yahoo.com> writes: |> > |> > I won't go into details, but one of the features of the ISO VT design |> > was that it allowed parallelism between windows - i.e. two applications |> > could interact with two separate windows without serialising through |> > the GUI server. That is forbidden by the X design. |> |> If a particular application designer wants to do it that way, it can be |> done although the X design might impose a perfomance/ latency penatly |> tor being used in non-standard ways. Refer to the proceedings of the |> (circa1990) 5th annual conference on Distributed Memory Computing for |> an example of the implementation of an X client consisting of multiple |> processes on multiple computers (or multiple nodes on a multicomputer). No, it can't, because the design forces the handshaking between the X Server and the lowest-level client - if that is what you want to avoid, you are stuffed. You also don't get the RAS features of a better design, because you can't stop another client from doing horrible things to you. The new SSH security extensions for X are based on a separate layer that clobbers a certain number of such things - but, if a client has a direct X connexion, they don't help. Oh, and they blow most clients out of the water as soon as the user attempts to do a cut-and-paste (for Emacs, even within the same window!) Hell, I designed a wrote a distributed client of the sort you are describing in about 1987, only to discover that the X11.3 Toolkit and Motif 1.1 widget set were such bug-ridden heaps of junk as to be completely unusable. It wasn't until the next versions that any of the distributed clients started to use them, which might indicate something. Regards, Nick Maclaren.
From: Andrew Reilly on 22 Dec 2006 09:06 On Fri, 22 Dec 2006 10:52:09 +0000, Nick Maclaren wrote: > See if you can find anything on NeWS I don't think that it's any surprise that the guys originally behind NeWS went on to develop Java. If you're going to push rendering functionality down to the terminal, and you can't convince the app programmers to do that in postscript, then... The app programmers don't seem to have really jumped on the Java client-gui/server-app bandwagon with any great zeal, though. These days they seem to want to do the GUI in html and javascript. Don't understand that one, myself. Cheers, -- Andrew
From: Joe Seigh on 22 Dec 2006 09:39 Andrew Reilly wrote: > On Fri, 22 Dec 2006 10:52:09 +0000, Nick Maclaren wrote: > > >>See if you can find anything on NeWS > > > I don't think that it's any surprise that the guys originally behind NeWS > went on to develop Java. If you're going to push rendering functionality > down to the terminal, and you can't convince the app programmers to do > that in postscript, then... > > The app programmers don't seem to have really jumped on the Java > client-gui/server-app bandwagon with any great zeal, though. These days > they seem to want to do the GUI in html and javascript. Don't understand > that one, myself. > Early on running with Java enabled in your browser was a good way to lock things up and force a restart. This may have inhibited widespread adoption of Java on the client side. Also, javascript is less restrictive. It lets you do things that the Java security model won't let you do. Remember, these days it's still more important to be able to do kewl things than to have robust security. The Java gui? It's threaded. There's an event handling thread. Most programmers can't deal with that. STM (software transactional memory) is a huge area of research precisely because of that since it eliminates the deadlock issue that most programmers don't know how to avoid. I once figured out a way to get it so you could have multiple event handling threads process events concurrently. But if programmers have difficulty with a single event handling thread, we're not likely to go that route to better parallelism. -- Joe Seigh When you get lemons, you make lemonade. When you get hardware, you make software.
From: "Peter "Firefly" Lund" on 22 Dec 2006 12:24 On Fri, 22 Dec 2006, Nick Maclaren wrote: > have said. The font manager, window manager, Toolkit and widget designs > (which are horribly entangled in largely unspecified ways) are far > worse. What font manager? What toolkit? > I won't go into details, but one of the features of the ISO VT design Actually, I think you /should/ go into details. Your knowledge of X seems to be rather different from mine. Maybe we could both stand to learn something? I, for one, would really like to learn how a mouse click or a key press in an input field causes 10 context switches. In detail. -Peter
From: Nick Maclaren on 22 Dec 2006 14:23
In article <Pine.LNX.4.61.0612221821130.13753(a)ask.diku.dk>, "Peter \"Firefly\" Lund" <firefly(a)diku.dk> writes: |> |> > have said. The font manager, window manager, Toolkit and widget designs |> > (which are horribly entangled in largely unspecified ways) are far |> > worse. |> |> What font manager? |> What toolkit? I keep hearing about these environments that run nothing but an X Server and some clients, but I have never had anyone told me where they are used. Today. I know damn well that they WERE used, back before the rest of the edifice was perpetrated. Perhaps you would like to explain why you don't regard them as an essential part of the X Windowing System? |> Actually, I think you /should/ go into details. Your knowledge of X seems |> to be rather different from mine. Maybe we could both stand to learn |> something? |> |> I, for one, would really like to learn how a mouse click or a key press in |> an input field causes 10 context switches. In detail. It's a heck of a long time ago now, but it went something like this: User presses the key, which causes: * Keyboard driver picks up the I/O event, munges it a bit and passes it to: X Server to pick up the event, create an X event and passes it to: [ Window manager, which decides it doesn't need it ] X client, which creates X request to highlight field and passes it to: * X Server, which updates screen and passes it to: Display driver, which actually updates the screen User releases the key, which causes: * Keyboard driver picks up the I/O event, munges it a bit and passes it to: X Server to pick up the event, create an X event and passes it to: [ Window manager, which decides it doesn't need it ] X client, which does action, creates X request and passes it to: * X Server, which updates screen and passes it to: Display driver, which actually updates the screen The lines in square brackets will depend on the window manager settings and the actual key combinations. Motif (which was the flavour of the month at the time I did the analysis) more-or-less required all events. The lines marked with asterisks can sometimes be 'eliminated' by having the X server drive the devices directly, but they couldn't be in the context I was interested in when I first did this analysis. I don't know how often they can be today. HOWEVER, it should also be noted that an upper-case character repeats most of the above for BOTH the shift key AND the actual key - in fact, the only steps that the shift key omits are the last two for press and release. Please note that, despite claims by dogmatists, switching in and out of a driver IS a context switch - I will accept that a mere fast call interrupt is not, but the costs of switching between an application and driver and conversely are about the same as switching between two applications. So I make it that the MINIMUM is 6 context switches for any character, and 10 for an upper-case or control character. And not all systems will do as well. Regards, Nick Maclaren. |