Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!uwm.edu!zaphod.mps.ohio-state.edu!sdd.hp.com!decwrl!ucbvax!bloom-beacon!HPLSLH.HPL.HP.COM!hoyle
From: hoyle@HPLSLH.HPL.HP.COM (Steve Hoyle)
Newsgroups: comp.windows.x
Subject: Re: what's most important to you for R5?
Message-ID: <9006292334.AA25368@hplslh.hpl.hp.com>
Date: 29 Jun 90 23:34:50 GMT
References: <9006222202.AA17654@expire.lcs.mit.edu>
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
Lines: 27


I would like to see the server redesigned internally so that the server
procs (the procedures which directly service protocol requests such as
procCreateWindow and ProcCopyArea) are re-entrant and can be exposed
as a public library. With support for dynamic linking Xlib could be
implemented to decide at runtime to either work as it does now over a
stream connection (to service a remote client), or in terms of new code
based directly on the server proc library (to service a local client).

For X servers running on workstations this architecture could be used to
improve the interactive performance of remote clients as well as local
clients. Toolkit servers running on the X server machine, for example,
could use the proc server path of Xlib to make widget/server
conversations more efficient. Ideally a server/Xlib shared queue
mechanism for dispatching events would be part of the new proc library.

These suggestions are essentially a step beyond multi-threading in the
server. It seems to me, however, that in either case the most difficult
part would be to satisfy (with efficiency) all of the re-entrancy
requirements. If multi-threading in the server is to be attempted for
R5, would it be much more difficult to support a public server proc
library?


Steve Hoyle
Hewlett-Packard Laboratories
hoyle@hplabs.hp.com