Most X server crashes that happend to me was from the (shitty) xfs font server found under redhat.
Hetz On Sunday 21 April 2002 23:04, Oron Peled wrote: > 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] ================================================================= 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]
