> For most, there isn't any sane thing to do > without a display other than (maybe save > some critical info and) quit.
> If the process is interactive and lost its > display, what other sane choice exists? Why not wait until it's reconnected (via some currently not existing command/signal) to the X-server? I don't see how a display can be so critical that an application can't run (or simply wait) without it. How is, from the high-level point of view, turning the X server off any different from turning off the monitor? > However, there is a lot of "state" stored in > the X-server (Graphics-Context etc.), Hmm, I guess this was my confusion... I'm a Java developer, so I'm used to everything display related to be event driven. That is, in Java (AWT and Swing at least), the application is supposed to always keep all the state, and be able to paint itself at any moment. Under such a model, the X-server wouldn't need to keep any state - whenever it's restarted, the window manager would simply ask all the windows to repaint themselves, restoring everything. Or am I missing something here? > and all of a sudden: KABBBOOOOOMMM..... > Sorry, all your state is lost... Well, like I said, I thought the applications were supposed to keep all the state, not the X-server. Alexander Maryanovsky. ----- Original Message ----- From: Oron Peled <[EMAIL PROTECTED]> Date: Sun, 21 Apr 2002 23:04:32 +0300 To: [EMAIL PROTECTED] Subject: Re: X server crashes > On Sun, 21 Apr 2002 18:50:10 +0200 > "Alexander Maryanovsky" <[EMAIL PROTECTED]> wrote: > > > So I guess I have two questions: > > 1. What is the technical reason processes crash when the > > X server they're running under crashes? > > They loose the connection (Stream Socket -- TCP or Local). > For most, there isn't any sane thing to do without > a display other than (maybe save some critical info and) quit. > > > 2. What (if any) is the high-level (design-level) reason > > that such a thing is allowed? > > If the process is interactive and lost its display, what > other sane choice exists? > > If the process has important functionality other than GUI, > than the programmer should: > 1. Either check return values on each call to xlib and > develop his own strategy (tedious and error prone). > 2. Acknowledge that his design is flawed. It should be: > A. Separate functional process for the non-interactive > job. > B. Separate display oriented process > C. Some IPC and glue logic between the two. > You should note that I've just advertized the ancient but > solid Model-View-Controler design. > > > Why can't one put up a proxy between the processes and the > > X server which would delegate everything to it, make X server > > crashes transparent to the processes and allow restarting > > the X server (again transparently to the processes) when it > > goes down? It seems like a fairly simple thing to do... > > You could put a proxy between them (there are proxies like > that for other purposes -- like sending to multiple displays). > However, there is a lot of "state" stored in the X-server > (Graphics-Context etc.), so your proxy should store a copy > of everything, and upon reconnection to the freshly born > X-server, it should "replay" all the state creating commands. > > So it isn't simple, and the "replay" time is proportional > to the "history" of the X-server.... not so good. > > My advice -- there is no substitute for good design of the > application. A major bad example in this respect is > web-browsers: All of them (the whole concept of them) is > big-bloated-application that does multitude of tasks in > a single application (and normally on a single TCP port -- 80). > > So, if you have gazillion browser windows open on different > URLS, many of them in the middle of a session (forms + cookies > + javascript), some with hidden state (Flash, sound, some other > behemoth) and all of a sudden: KABBBOOOOOMMM..... > > Sorry, all your state is lost... > > > ---------------------------------------------------------------- > Oron Peled Voice/Fax: +972-4-8228492 > [EMAIL PROTECTED] http://www.actcom.co.il/~oron > > "Those who do not understand Unix are condemned to reinvent it, > poorly." > (H. Spencer) > > ================================================================= > To unsubscribe, send mail to [EMAIL PROTECTED] with > the word "unsubscribe" in the message body, e.g., run the command > echo unsubscribe | mail [EMAIL PROTECTED] > > -- _______________________________________________ Sign-up for your own FREE Personalized E-mail at Mail.com http://www.mail.com/?sr=signup ================================================================= To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
