emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Frame ordering


From: martin rudalics
Subject: Re: Frame ordering
Date: Sat, 12 Jun 2010 10:01:35 +0200
User-agent: Thunderbird 2.0.0.21 (Windows/20090302)

>> I'd write a simple function to reorder frames, make it callable from
>> Lisp, and test it from there first.
>
> OK, that works.
> What next?
> `handle-switch-frame' could be defined in Lisp anyway, calling the current 
Fhandle_switch_frame primitive.

I don't think so.  IIUC it's purpose is to hide do_switch_frame from
Elisp.

> That said, why did the same not work in do_switch_frame, and why did my other 
variant (that I posted) lead to hangs and crashes?
[...]
> (defun my-handle-switch-frame ( event)
>   (interactive "e")
>   (handle-switch-frame event)
>   (set-latest-frame (selected-frame)))

I can only guess.  do_switch_frame handles an event and when the frame
list is in the state of restructuring and an event occurs, you might end
up with a broken frame list (or a broken window or buffer list given the
fact that do_switch_frame calls `select-window').

In addition, as I recently noticed in the buffer list handling routines,
frame/window/buffer lists are frequently updated via Fdelq and that
function can quit.  I suppose that in all these cases we'd have to use
delq_no_quit (and similar functions) instead to be on the safe side.

Your `my-handle-switch-frame' seems safe because you serialized
`set-latest-frame' with do_switch_frame - so you won't suffer any of the
problems above.  If, however, you were able to interrupt a call to
`set-latest-frame' somehow (maybe by running it in an infinite loop),
you might be able to produce a crash too.

martin



reply via email to

[Prev in Thread] Current Thread [Next in Thread]