Moving discussion from xemacs-patches to xemacs-beta.
>>>> "ms" == Michael Sperber
ms> It looks OK to me, but since you seem to be knowledgeable in
ms> things X, I would be interested in a diagnosis on why the old
ms> code failed. It does look like a bug in Xt, doesn't it?
What's happening here is that people are assuming session management
and logging out from xdm/gdm/whatever, without shutting down XEmacs.
That's the situation that generates the symptom (lingering XEmacs
process consuming 100% CPU).
gdm, as you would expect, takes all the care of a Microsoft
operating system in shutting down. Anyway, XEmacs loses its last X
device and goes into a spin in that CONSOLE_DEVICE_LOOP. A real
session manager would shut down XEmacs (the user has logged out of the
session that XEmacs was started in, and XEmacs is a foreground app
there). xdm and xsm both do this.
I believe (but haven't checked) that the patch "works" because after
finding no connections the code falls through to a place where XEmacs
realizes it has no live consoles and exits.
I don't consider it a bug in Xt; note that XtAppPending is a building
block for event loops, not an event loop, so I think it's our
responsibility to check for live dpys. (I hate it, but the "caller
provides correct input or I crash" policy is consistent throughout
I think in the long run what we want to do is make XEmacs a server
process, with display clients. (Isn't it your comment that "maybe we
can finally move the first frame into startup.el"? Whoever wrote that
inspired this wacky idea.)
 At least I have come to. I will _not_ use GTK/GNOME software
anywhere near security or system management functions, and I'm nervous
about the results produced by Gnumeric ;-)
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
My nostalgia for Icon makes me forget about any of the bad things. I don't
have much nostalgia for Perl, so its faults I remember. Scott Gilbert c.l.py