Path: utzoo!attcan!uunet!lll-winken!ames!mailrus!tut.cis.ohio-state.edu!bloom-beacon!SUN.COM!dshr
From: dshr@SUN.COM (David Rosenthal)
Newsgroups: comp.windows.x
Subject: Re: A Thought on X Terminals
Message-ID: <8902262128.AA04910@devnull.sun.com>
Date: 26 Feb 89 17:45:18 GMT
Sender: daemon@bloom-beacon.MIT.EDU
Organization: The Internet
Lines: 115


	"Don't,  don't believe,  don't believe the hype."
		Public Enemy

> >to see the above have a reasonable performance in the near future.  The
> >typical style of developing X applications would have to change drastically
> >to allow a server to run in limited memory (<16meg) without paging resources.
> >Especially if the user expects to run more than 10-12 large toolkit clients
> >simultaneously.
> >
> >Dick Schoeller			| ARPA:  schoeller%gvriel.dec@decwrl.dec.com
> 
> In defense of Dick St Peters servers *obviously* can run on such
> systems, that's exactly what Visual, NCD and others are selling! I
> don't understand your objection.
> 
The point that Dick Schoeller was making was the one I have been making
for about 18 months now.  I can't understand why its so hard to get people
to hear it.  Here we go again,  at somewhat more length than before.
[I apologize if I'm getting repetitive on this point,  but I believe
that as one of the designers of X I have a professional responsibility
to counter the misleading and irresponsible marketing of the X terminal
companies].

Current X clients CRASH when they get a Alloc error.
X terminals with no VM are likely to generate Alloc errors frequently.
For example,  the X server on the DEC PMAX in their suite at Usenix
when I used it had been used to run a lot of sophisticated X clients
simultaneously.  It was 17meg big (resident set size was 7meg).  Of course,
this was pre-production software and it may have had leaks,  but how many
X terminals will have even half that much memory?

Changing this involves a completely different style of client-writing,
which no-one has designed yet.  It would be basically transaction-oriented,
to allow recovery from Alloc errors in a workable way.

The fundamental problem here is a change in design philosophy between
X10 and X11.  In effect X10 was stateless,  and clients couldn't
allocate resources in the server (for example,  off-screen pixmaps).
X11 is statefull,  and clients can allocate resources in the server.
The reason for doing this is that much greater performance can be achieved
in this way.

When a client of a statefull service that is being shared with other clients
gets an Alloc error,  there may be nothing that IT can do to recover.
The problem may be that some other client has just allocated too much resource,
and that the only route to recovery involves the other client doing something.
This problem is common to all statefull services,   for example file systems,
and can always lead to deadlock.

OK,  you say,  we'll just tell the user what's going on,  and let him or her
get us out of the mess.  Easy,  except that to communicate with the user you
have to use X11 protocol and the requests you send to do it may in themselves
cause Alloc errors,  and .......

Sounds familiar,  doesn't it?  This is basically the multi-access database
problem,  with additional problems caused by asynchronous error notification
and the need to use the database itself to communicate with the user about
the problems involved in using the database and how to recover from them.
Ask the database people how easy it is to cope with the problem even without
these extra complications.

No current X applications are written like database access programs,  with
trqansactions that can be backed-out of to get back to a known state before
the Alloc error.  As I understand the Intrinsics,  they cannot support such
a mode of programming.  Indeed,  its my belief that to fix this problem we
will have to build transaction support into Xlib.  So,  Alloc errors are
likely to be fatal for a long time.

Given that Alloc errors are fatal,  there are two routes to living with the
problem:

-	Give the X terminal an MMU, and page to an NFS server. Looks a lot
	like a diskless workstation,  doesn't it?
-	Rewrite the X clients you are going to use never to do any X request
	that can cause memory to be allocated in the server,  or do them all
	up-front.  This is hard because:

	-	Any X request can potentially cause the server to
		allocate memory.
	-	Avoiding just the requests you KNOW allocate memory
		involves a severe performance hit (why was it statefull
		in the first place?)

The bottom line is,  X terminals are being marketed under two claims:

-	They are cheaper than workstations.
-	They run the same X clients as workstations.

Neither of these claims is true in practice:

-	Using X terminals instead of workstations does not change the
	set of processes being run,  nor the amount of disk/RAM/CPU
	needed to run them.  It merely moves them from one place to
	another.  It may be that you can buy the necessary total amount
	of disk/RAM/CPU cheaper as a set of workstations with a file
	server,  or as a set of X terminals with a timesharing machine,
	but in neither case is the price tag on the thing on your desk
	the only thing to consider.

-	A non-VM X terminal will only run a small set of simple X clients
	safely.  Overloading it with complex clients which use server
	resources to implement a high-performance graphical user interface
	is dangerous - clients will start to crash randomly (hardly
	user-friendly behaviour).  If all you want from X is a way of
	running several terminal emulators at once,  an X terminal is
	OK.  But the whole idea of X was to get away from simple terminal-type
	interfaces and make a real operating system look more like
	the "computer you already know how to use".  If I can't in
	practice run the clients that were the raison d'etre for X,
	I think I'm entitled to feel cheated.

Caveat Emptor.

	David.