2:37 a.m.
Jeff Mincy <jeff(a)delphioutpost.com> writes:
I just spent, oh maybe, 5 minutes looking at the source. I
don't
see how it could do anything other than loop.
It looks like x_IO_error_handler is called, sets
DEVICE_X_BEING_DELETED (as you stated), then throws to top level,
which is inside of an infinite for loop.
Yes, but that infinite for loop calls the command loop, doesn't it?
And the command loop should call the event loop, which should execute
the enqueued magic event, which should cause the last available device
getting deleted, which should cause XEmacs to exit gracefully.
Can you see why the magic event doesn't fire or, if it does, why
doesn't XEmacs exit?
Does it ever exit gracefully?
Deleting the last device should call graceful exit; for example, this
exits:
xemacs -nw -eval "(delete-device (selected-device) t)"
2:46 a.m.
New subject: Continuous running (was Re: gnuclient *feature* -- crash when frames lose X connection)
> "Hrvoje" == Hrvoje Niksic <hniksic(a)arsdigita.com>
writes:
Hrvoje> Jeff Mincy <jeff(a)delphioutpost.com> writes:
> Does it ever exit gracefully?
Hrvoje> Deleting the last device should call graceful exit; for
Hrvoje> example, this exits:
Hrvoje> xemacs -nw -eval "(delete-device (selected-device) t)"
Off topic, is it possible to force XEmacs not to exit when the last
device gets deleted? In particular, what I'm aiming for is for
XEmacs to keep running on my unix box when my Windows box crashes,
killing my ssh sessions. Once I'm back up, ideally I would ssh back
in, run gnuclient -nw, and reconnect to my running XEmacs, not having
to recover various VM and BBDB buffers.
--
Sam Mikes
smikes(a)cubane.com
11:30 a.m.
New subject: Continuous running (was Re: gnuclient *feature* -- crash when frames lose X connection)
>>>> "smikes" == Samuel Mikes
<smikes(a)cubane.com> writes:
smikes> Off topic, is it possible to force XEmacs not to exit
smikes> when the last device gets deleted?
I don't think so. It would be nice, of course. Then the next thing
would be to embed the XEmacsServer in a loadable kernel module ;-)
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Don't ask how you can "do" free software business;
ask what your business can "do for" free software.
2:12 p.m.
New subject: Continuous running (was Re: gnuclient *feature* -- crash when frames lose X connection)
Stephen J. Turnbull writes:
>>>>> "smikes" == Samuel Mikes
<smikes(a)cubane.com> writes:
smikes> Off topic, is it possible to force XEmacs not to exit
smikes> when the last device gets deleted?
I don't think so. It would be nice, of course. Then the next thing
would be to embed the XEmacsServer in a loadable kernel module ;-)
It's not exactly what Samuel was asking, but you can always start it
up as "xemacs -unmapped", which basically gives you the same
effect... I start xemacs this way and do all my edits via
gnuclients... when I exit the last gnuclient frame, the unmapped
xemacs frame is still running.
3:35 p.m.
New subject: Continuous running (was Re: gnuclient *feature* -- crash when frames lose X connection)
Charles G Waldman <cgw(a)alum.mit.edu> writes:
Stephen J. Turnbull writes:
> >>>>> "smikes" == Samuel Mikes <smikes(a)cubane.com>
writes:
>
> smikes> Off topic, is it possible to force XEmacs not to exit
> smikes> when the last device gets deleted?
>
> I don't think so. It would be nice, of course. Then the next thing
> would be to embed the XEmacsServer in a loadable kernel module ;-)
It's not exactly what Samuel was asking, but you can always start it up
as "xemacs -unmapped", which basically gives you the same effect... I
start xemacs this way and do all my edits via gnuclients... when I exit
the last gnuclient frame, the unmapped xemacs frame is still running.
If you combine this with the Xvfb server from XFree86[1], you can do some
pretty spiffy stuff. If you start Xvfb and tell XEmacs to start with
'xemacs -display :2.0 -unmapped', you XEmacs will always be around.
-bp
[1] From the man page: "Xvfb is an X server that can run on machines with
no display hardware and no physical input devices. It emulates a dumb
framebuffer using virtual memory."
--
Ceterum censeo vi esse delendam
4:06 p.m.
New subject: Continuous running (was Re: gnuclient *feature* -- crash when frames lose X connection)
> "William" == William M Perry <wmperry(a)gnu.org>
writes:
William> Charles G Waldman <cgw(a)alum.mit.edu> writes:
> Stephen J. Turnbull writes:
> > >>>>> "smikes" == Samuel Mikes
<smikes(a)cubane.com> writes:
> >
> > smikes> Off topic, is it possible to force XEmacs not to
> > smikes> exit
> > smikes> when the last device gets deleted?
> >
> > I don't think so. It would be nice, of course. Then the next
> > thing would be to embed the XEmacsServer in a loadable kernel
> > module ;-)
Yes, exactly... or else boot with init=/usr/local/bin/xemacs
> It's not exactly what Samuel was asking, but you can always
start
> it up as "xemacs -unmapped", which basically gives you the same
> effect... I start xemacs this way and do all my edits via
> gnuclients... when I exit the last gnuclient frame, the unmapped
> xemacs frame is still running.
William> If you combine this with the Xvfb server from XFree86[1],
William> you can do some pretty spiffy stuff. If you start Xvfb and
William> tell XEmacs to start with 'xemacs -display :2.0 -unmapped',
William> you XEmacs will always be around.
Unfortunately, -unmapped only has meaning on X and gtk devices, and
I'm the guy with tty-only. I'll try a couple of things:
maybe I can implement initially-unmapped for tty devices without
too much pain, or else maybe I can create a null-device class.
According to what Bill says, installing X so I can use Xvfb sounds
like it should work.
And while I'm talking blue-sky, what I *really* want is to start
an XEmacs server on my unix box and then connect to it with gnuclient
from the windows box, with the gnuclient having a normal
XEmacs-on-msw interface. The server XEmacs would presumably have to
be compiled to know about the foreign widget toolkit, fonts, colors,
etc...
--
Sam Mikes
smikes(a)cubane.com
5:27 p.m.
New subject: Continuous running (was Re: gnuclient *feature* -- crash when frames lose X connection)
>>>> "smikes" == Samuel Mikes
<smikes(a)cubane.com> writes:
smikes> The server XEmacs would presumably have to be compiled to
smikes> know about the foreign widget toolkit, fonts, colors,
smikes> etc...
I don't think so. All of the widget stuff _must_ be done locally on
Windows, right? The rest of the stuff would live in ~/.xemacs/custom.el.
XEmacsServer shouldn't need to know.
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Don't ask how you can "do" free software business;
ask what your business can "do for" free software.
8:37 p.m.
New subject: Continuous running (was Re: gnuclient *feature* -- crash when frames lose X connection)
Samuel Mikes <smikes(a)cubane.com> wrote:
Unfortunately, -unmapped only has meaning on X and gtk devices,
and
I'm the guy with tty-only. I'll try a couple of things:
maybe I can implement initially-unmapped for tty devices without
too much pain, or else maybe I can create a null-device class.
According to what Bill says, installing X so I can use Xvfb sounds
like it should work.
And while I'm talking blue-sky, what I *really* want is to start
an XEmacs server on my unix box and then connect to it with gnuclient
from the windows box, with the gnuclient having a normal
XEmacs-on-msw interface. The server XEmacs would presumably have to
be compiled to know about the foreign widget toolkit, fonts, colors,
etc...
Well, this is horribly evil, but, in the meantime, you could do
what I'm doing: keep a vncserver running in the background. You can
have XEmacs running in X under VNC, and use gnuclient to connect to it
from ttys. Another advantage is that you can connect to it from
Windows, for a really ugly (but amazingly fast) way of accessing X11
from Windows (although the cygwin XFree86 server is probably a better
approach for this).
[ And what I'm doing is doubly-evil, in that I've got the box configured
to start the vncserver session (with my uid) at boot time. I'm
actually using it as a remote console. ;-) It's behind a firewall at
home, and accessed only from systems at home, and so I'm not too
concerned about security (vnc sends everything in the clear). ]
VNC is *really* nice.
--
Darryl Okahata
darrylo(a)soco.agilent.com
DISCLAIMER: this message is the author's personal opinion and does not
constitute the support, opinion, or policy of Agilent Technologies, or
of the little green men that have been following him all day.
9:54 p.m.
New subject: Continuous running (was Re: gnuclient *feature* -- crash when frames lose X connection)
Charles G Waldman writes:
Stephen J. Turnbull writes:
> >>>>> "smikes" == Samuel Mikes <smikes(a)cubane.com>
writes:
>
> smikes> Off topic, is it possible to force XEmacs not to exit
> smikes> when the last device gets deleted?
>
> I don't think so. It would be nice, of course. Then the next thing
> would be to embed the XEmacsServer in a loadable kernel module ;-)
It's not exactly what Samuel was asking, but you can always start it
up as "xemacs -unmapped"
i have a vague recollection of using the "screen" program to do
similar tricks... sorry but i cannot get more details out of my
head :-(
1:58 p.m.
New subject: Continuous running (was Re: gnuclient *feature* -- crash when frames lose X connection)
Samuel Mikes <smikes(a)cubane.com> writes:
Off topic, is it possible to force XEmacs not to exit when the last
device gets deleted?
What would such an XEmacs do? What events would it wait on?
In particular, what I'm aiming for is for XEmacs to keep running
on
my unix box when my Windows box crashes, killing my ssh sessions.
Once I'm back up, ideally I would ssh back in, run gnuclient -nw,
and reconnect to my running XEmacs, not having to recover various VM
and BBDB buffers.
Start XEmacs with `xemacs -unmapped -f gnuserv-start' to achieve the
effect you're aiming for.
5:28 p.m.
New subject: Continuous running (was Re: gnuclient *feature* -- crash when frames lose X connection)
> "Hrvoje" == Hrvoje Niksic <hniksic(a)arsdigita.com>
writes:
Hrvoje> Samuel Mikes <smikes(a)cubane.com> writes:
> Off topic, is it possible to force XEmacs not to exit when the
> last device gets deleted?
Hrvoje> What would such an XEmacs do? What events would it wait on?
Signals, I guess. Just because there are currently no active
consoles doesn't mean that a console couldn't later be created via
gnuclient. Exiting when there are no live consoles is pre-emptive if
gnuserv is running, even though it's the desired behavior 99% of the time.
> In particular, what I'm aiming for is for XEmacs to keep
running
> on my unix box when my Windows box crashes, killing my ssh
> sessions. Once I'm back up, ideally I would ssh back in, run
> gnuclient -nw, and reconnect to my running XEmacs, not having to
> recover various VM and BBDB buffers.
Hrvoje> Start XEmacs with `xemacs -unmapped -f gnuserv-start' to
Hrvoje> achieve the effect you're aiming for.
It sounds like this would work, but I'd need X since '-unmapped'
doesn't work for tty consoles. This thread has given me some ideas
to think about, and if something interesting comes of it I'll report
it back to the list.
--
Sam Mikes
smikes(a)cubane.com
1:10 p.m.
New subject: Continuous running (was Re: gnuclient *feature* -- crash when frames lose X connection)
Samuel Mikes writes:
>> In particular, what I'm aiming for is for XEmacs to keep running
>> on my unix box when my Windows box crashes, killing my ssh
>> sessions. Once I'm back up, ideally I would ssh back in, run
>> gnuclient -nw, and reconnect to my running XEmacs, not having to
>> recover various VM and BBDB buffers.
i mentioned screen in a previous post, but i was vague...
as i have problems similar to yours, and having this recollection of
screen being the/one solution, i tried to read screen's man page, and
all the pieces came to my mind
here is my recipe: please note that it's not as convenient as
gnuclient, and you have to type C-a a in place of a single C-a, as
screen use C-a as its escape character, but i can do as follows
local% [connect to some provider ＠56kbs]&
local% ssh gb(a)somehost.somewhere
remote# screen xemacs -nw
......
......
[the connection is abrubtly down:
i had to type the ssh escape "RET ~." to go back to my PC]
local% [re-connect to the same lousy (but extremely cheap :-) provider]&
local% ssh gb(a)somehost.somewhere
remote# screen -r
......
[back in xemacs exactly where i was when the connection was broken]
......
C-a d [this command detaches the screen session from the terminal]
remote# exit [note that xemacs still runs in the detached session]
local%
3:34 a.m.
New subject: gnuclient *feature* -- crash when frames lose X connection
On Wed, 24 Apr 2002, hniksic(a)arsdigita.com wrote:
Jeff Mincy <jeff(a)delphioutpost.com> writes:
> I just spent, oh maybe, 5 minutes looking at the source. I don't
> see how it could do anything other than loop.
>
> It looks like x_IO_error_handler is called, sets
> DEVICE_X_BEING_DELETED (as you stated), then throws to top level,
> which is inside of an infinite for loop.
Yes, but that infinite for loop calls the command loop, doesn't it?
And the command loop should call the event loop, which should execute
the enqueued magic event, which should cause the last available device
getting deleted, which should cause XEmacs to exit gracefully.
Can you see why the magic event doesn't fire or, if it does, why
doesn't XEmacs exit?
> Does it ever exit gracefully?
Deleting the last device should call graceful exit; for example, this
exits:
xemacs -nw -eval "(delete-device (selected-device) t)"
Ok. I spent 10 minutes looking at the code. I now understand the
code twice as much as I did before...
The function x_IO_error_handler enqueues a magic eval delete_device
event. Supposedly, doing this magic event will cause the device to exit.
After event is enqueued, the device is marked as being deleted.
int
x_IO_error_handler (Display *disp)
{
...
if (d)
enqueue_magic_eval_event (io_error_delete_device, dev);
DEVICE_X_BEING_DELETED (d) = 1;
Fthrow (Qtop_level, Qnil);
...
}
Then we go over to handle_magic_event. The first thing that this code
does is checks to see if the frame is being deleted. If it is, magic
event function returns, and does not actually process the event.
Might this be the problem?
static void
emacs_Xt_handle_magic_event (Lisp_Event *emacs_event)
{
/* This function can GC */
XEvent *event = &emacs_event->event.magic.underlying_x_event;
struct frame *f = XFRAME (EVENT_CHANNEL (emacs_event));
if (!FRAME_LIVE_P (f) || DEVICE_X_BEING_DELETED (XDEVICE (FRAME_DEVICE (f))))
return;
switch (event->type)
-jeff
5:11 p.m.
New subject: gnuclient *feature* -- crash when frames lose X connection
Jeff Mincy <jeff(a)delphioutpost.com> writes:
The function x_IO_error_handler enqueues a magic eval delete_device
event. Supposedly, doing this magic event will cause the device to
exit. After event is enqueued, the device is marked as being
deleted.
Yes, that might well be the problem.
8593
days inactive
8595
days old
13 comments
8 participants
participants (8)
-
Charles Waldman -
Darryl Okahata -
Giacomo Boffi -
Hrvoje Niksic -
Jeff Mincy -
Samuel Mikes -
Stephen J. Turnbull -
William M. Perry