[<<] [<] Page 1 of 1 [>] [>>] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
Re: [linuxce-devel] Microwindows architecture explained
From: "Greg Haerr" ####@####.#### Date: 31 Oct 1999 18:07:07 -0000 Message-Id: <003a01bf23b8$f5e8e9e0$15320cd0@gregh> ----- Original Message ----- From: Jay Carlson ####@####.#### : I think I figured out why Nano-X is so slow. All requests, even just : drawing single pixels, involve a round trip to the server. When a drawing : request is sent to the server, the client blocks until it reads the one-byte : reply. Alex knows his code is slow, and was going to rewrite it. I think your critical insight about the when the client and server processes context switch should drive the design. That is, just like X, _all_ requests should be buffered until the next call to GetNextEvent, unless they absolutely require information from the server, like GetInfo requests. We can also assume that the client/server connection is reliable (hell, it's not even UDP, it's UNIX sockets...) so there's not a big need to error check the status. I'll take a look at the X protocol and see whether there's a wire-level synchronization capability in the rare case that things really do get hosed up. : : X is a good deal smarter about this. Most operations, including drawing, do : not require a reply. Error conditions are treated like events and signalled : asynchronously. : Although more complicated, an async error event is a good idea. If we're using UNIX sockets, it's unlikely this will ever happen. : This is particularly clever because it allows both the client library and : the underlying pipe/TCP stream/etc to buffer requests. Any client operation : that really requires a reply flushes the outbound request buffer. : : Consider a Nano-X client wanting to draw ten lines and then wait for an : event. Each small request blocks the client until the server issues its : reply, so we must context switch at least twenty times. With X-style : buffering, the ten line draw messages get pushed all at once and then the : client waits; the server then chews its way through the received requests : and will context-switch back to the client when there's actually an event. : : I don't enough about X to hate it the way some people do, but the core X : protocol and some parts of Xlib look like they were designed by very smart : people. : : Jay I'll add a client/server rewrite to the list, and try to push up it's priority. Greg | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
Re: [linuxce-devel] Microwindows architecture explained
From: Alan Cox ####@####.#### Date: 31 Oct 1999 21:23:28 -0000 Message-Id: <E11i2EX-0001lV-00@the-village.bc.nu> > it's UNIX sockets...) so there's not a big need to error check the status. > I'll take a look at the X protocol and see whether there's a wire-level > synchronization > capability in the rare case that things really do get hosed up. X leaves reliability problems to the transport layer (which IMHO is the right thing to do). If your tcp connection dies the app goes pop too. > Although more complicated, an async error event is a good idea. If we're using > UNIX sockets, it's unlikely this will ever happen. The X idea is that most operations dont fail ever - eg drawing a line, so these calls are void and queue the operation. Instead X can return an error to those calls that is delayed from the call > | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
[<<] [<] Page 1 of 1 [>] [>>] |