signal handling bogosities

signal handling bogosities

[Miles Bader]

I've got another core dump from my face-realization-filter code
(see attached backtrace), and seeing it raises some more fundamental
questions about the redisplay code.

Basically the problem seem to be that it's evaluating lisp code in a
place where it shouldn't, though I'm not sure I understand all the rules
for exactly where is OK and where is not.

The point of failure is this, in `Feval' (eval.c, line 1983):

  if (handling_signal)
    abort ();

it _is_ in a signal handler, specifically:

   #16 0x080dc6f2 in input_available_signal (signo=29)
       at /usr/local/src/emacs/src/keyboard.c:6633

That signal results in `note_mouse_movement', and then
`note_mouse_highlight' being called:

   #11 0x080b2345 in note_mouse_highlight (f=0x850aa18, x=184, y=260)
       at /usr/local/src/emacs/src/xterm.c:7407
   #12 0x080b162e in note_mouse_movement (frame=0x850aa18, event=0xbffd1064)
       at /usr/local/src/emacs/src/xterm.c:6893
   #13 0x080b5f05 in handle_one_xevent (dpyinfo=0x84f5490, eventp=0xbffd13ac, 
       bufp_r=0xbffd1418, numcharsp=0xbffd141c, finish=0xbffd13a8)
       at /usr/local/src/emacs/src/xterm.c:11291

note_mouse_highlight then tries to figure out the proper mouse-face-id,
which calls face realization, and if realize-face-filter-functions has
a non-nil value, calls the lisp interpreter, and thus dies as seen.

Now, I suppose that calling the lisp interpreter inside a signal handler
might be a bad thing, and so perhaps the check in Feval is reasonable
(though the byte-code evaluator _doesn't_ seem to check; perhaps if I
compiled my code, it would work :-).

What concerns me is that even without that, it seems to be doing an
absurd amount of stuff inside the the signal handler, to the extent that
it seems very hard to be sure _what_ code will end being called.  After
it does the face lookup that killed me, it seems to go and actually
display the mouse face, and in other branches of the code the whole
redisplay engine seems to be invoked, for exposure events (I don't know
whether that can result in lisp code being called, but it seems as if it
could -- given the complexity of redisplay, it's kind of hard to tell).

So what do people think?  The whole thing seems really broken to me, but
I don't have a complete grasp of the code.  How hard would be to
restructure things to just queue this stuff for an event-loop outside
the signal handler to handle?

Thanks,

-Miles



Here's the full backtrace:


#0  0x402eac51 in kill () from /lib/libc.so.6
#1  0x080d377a in abort () at /usr/local/src/emacs/src/emacs.c:412
#2  0x0812b44a in Feval (form=1481199500)
    at /usr/local/src/emacs/src/eval.c:1984
#3  0x081292b2 in Fprogn (args=1481198692)
    at /usr/local/src/emacs/src/eval.c:424
#4  0x0812c586 in funcall_lambda (fun=1481198684, nargs=1, 
    arg_vector=0xbffd0b08) at /usr/local/src/emacs/src/eval.c:2921
#5  0x0812c1b1 in Ffuncall (nargs=2, args=0xbffd0b04)
    at /usr/local/src/emacs/src/eval.c:2798
#6  0x0812a880 in internal_condition_case_2 (bfun=0x812bebc <Ffuncall>, 
    nargs=2, args=0xbffd0b04, handlers=405463828, 
    hfun=0x805cd10 <safe_eval_handler>) at /usr/local/src/emacs/src/eval.c:1435
#7  0x0805ce03 in safe_call (nargs=2, args=0xbffd0b04)
    at /usr/local/src/emacs/src/xdisp.c:1400
#8  0x0805ce38 in safe_call1 (fn=408560044, arg=1220621664)
    at /usr/local/src/emacs/src/xdisp.c:1420
#9  0x080a2a9e in realize_face (cache=0x850f090, attrs=0xbffd0c68, c=0, 
    base_face=0x0, former_face_id=-1) at /usr/local/src/emacs/src/xfaces.c:6723
#10 0x080a3b95 in face_at_buffer_position (w=0x8cf3e78, pos=1983, 
    region_beg=0, region_end=0, endptr=0xbffd0d6c, limit=1984, mouse=1)
    at /usr/local/src/emacs/src/xfaces.c:5648
#11 0x080b2345 in note_mouse_highlight (f=0x850aa18, x=184, y=260)
    at /usr/local/src/emacs/src/xterm.c:7407
#12 0x080b162e in note_mouse_movement (frame=0x850aa18, event=0xbffd1064)
    at /usr/local/src/emacs/src/xterm.c:6893
#13 0x080b5f05 in handle_one_xevent (dpyinfo=0x84f5490, eventp=0xbffd13ac, 
    bufp_r=0xbffd1418, numcharsp=0xbffd141c, finish=0xbffd13a8)
    at /usr/local/src/emacs/src/xterm.c:11291
#14 0x080b654d in XTread_socket (sd=0, bufp=0xbffd244c, numchars=4096, 
    expected=1) at /usr/local/src/emacs/src/xterm.c:11719
#15 0x080dc531 in read_avail_input (expected=1)
    at /usr/local/src/emacs/src/keyboard.c:6470
#16 0x080dc6f2 in input_available_signal (signo=29)
    at /usr/local/src/emacs/src/keyboard.c:6633
#17 0x402eabd8 in sigaction () from /lib/libc.so.6
#18 0x08057271 in sit_for (sec=30, usec=0, reading=1, display=1, 
    initial_display=0) at /usr/local/src/emacs/src/dispnew.c:6247
#19 0x080d8305 in read_char (commandflag=1, nmaps=2, maps=0xbfffeb60, 
    prev_event=405463780, used_mouse_menu=0xbfffebac)
    at /usr/local/src/emacs/src/keyboard.c:2635
#20 0x080de7a0 in read_key_sequence (keybuf=0xbfffecb0, bufsize=30, 
    prompt=405463780, dont_downcase_last=0, can_return_switch_frame=1, 
    fix_current_buffer=1) at /usr/local/src/emacs/src/keyboard.c:8398
#21 0x080d63f8 in command_loop_1 () at /usr/local/src/emacs/src/keyboard.c:1478
#22 0x0812a689 in internal_condition_case (bfun=0x80d60f0 <command_loop_1>, 
    handlers=405560436, hfun=0x80d5d04 <cmd_error>)
    at /usr/local/src/emacs/src/eval.c:1352
#23 0x080d5fc8 in command_loop_2 () at /usr/local/src/emacs/src/keyboard.c:1279
#24 0x0812a21d in internal_catch (tag=405521716, 
    func=0x80d5fa4 <command_loop_2>, arg=405463780)
    at /usr/local/src/emacs/src/eval.c:1112
#25 0x080d5f73 in command_loop () at /usr/local/src/emacs/src/keyboard.c:1258
#26 0x080d5ac0 in recursive_edit_1 ()
    at /usr/local/src/emacs/src/keyboard.c:974
#27 0x080d5bf0 in Frecursive_edit ()
    at /usr/local/src/emacs/src/keyboard.c:1030
#28 0x080d4a83 in main (argc=3, argv=0xbffff274)
    at /usr/local/src/emacs/src/emacs.c:1659

-- 
Yo mama's so fat when she gets on an elevator it HAS to go down.

Re: signal handling bogosities

[Gerd Moellmann]

Miles Bader <miles@lsi.nec.co.jp> writes:
> Eli suggested that you might be a good person to ask about the
> following problem (I presume you're not subscribed to emacs-devel).

Hi Miles.  No, I'm not reading emacs-devel.

[...]

> Basically the problem seem to be that it's evaluating lisp code in a
> place where it shouldn't, though I'm not sure I understand all the rules
> for exactly where is OK and where is not.

The rule is pretty simple: one must not modify the state of the Lisp
interpreter while handling a signal because the Lisp interpreter isn't
reentrant.

[...]

> Now, I suppose that calling the lisp interpreter inside a signal handler
> might be a bad thing, and so perhaps the check in Feval is reasonable
> (though the byte-code evaluator _doesn't_ seem to check; perhaps if I
> compiled my code, it would work :-).

I don't think so :).

The Lisp interpreter doesn't protect itself against signals, that is,
the signal might have interrupted the interpreter at an arbitrary
point.  It's very dangerous to change anything from a signal handler
that the Lisp interpreter itself might be working on in the normal
thread of execution.

The fact that handling_signal is only checked in one place is just
because I didn't want to slow down things.  IIRC, there wasn't any
such check before I added one which meant that one could screw up
Emacs without even noticing.

> What concerns me is that even without that, it seems to be doing an
> absurd amount of stuff inside the the signal handler, to the extent that
> it seems very hard to be sure _what_ code will end being called.  

Well said.

> After it does the face lookup that killed me, it seems to go and
> actually display the mouse face, and in other branches of the code
> the whole redisplay engine seems to be invoked, for exposure events
> (I don't know whether that can result in lisp code being called, but
> it seems as if it could -- given the complexity of redisplay, it's
> kind of hard to tell).

The code in xterm.c carefully avoids modifying that state of the Lisp
interpreter asynchronously (or let's say it did when I resigned; I
don't know what it does now), but you're absolutely right that it's
hard to see it does that without studying the code in detail.

> So what do people think?  The whole thing seems really broken to me, but
> I don't have a complete grasp of the code.  How hard would be to
> restructure things to just queue this stuff for an event-loop outside
> the signal handler to handle?

I felt this way of doing X from a signal handler is broken ever since
I started to write the new redisplay and studied that part of the code
in Emacs 19.

And there's not just the problem that Lisp can't be called from the
signal handling code, it also goes the other way 'round.  Normal code
can be interrupted at any time by a signal, so anything used in
xterm.c had better be in a consistent state when the signal is
processed; that's the reason why regions of code in xfaces.c, for
example, protect themselves against signals.

And to add to that, some Xt functionality (specifically timeouts) is
tightly coupled to having an Xt event loop.  That's why widgets using
timeouts, like some scroll bar and menu widgets, don't work well with
Emacs, or don't work without jumping through hoops.

BTW, XEmacs developers told me it is using a normal event loop instead
of the signal abomination.

My feeling is that the cost of restructuring the code to use an event
loop could be pretty high, but I've never investigated this very
deeply because Richard thought the current way of doing things is
good, and an event loop is an abomination :).  There were lots of
other things to do anyway, so I didn't pursue this further.

Specifically for mouse-highlighting there may be a cheaper solution,
though.  IIRC, I once talked with Stefan Monnier about generating
mouse-highlight input events for mouse highlights instead of doing the
display directly when handling the mouse movement event (analogous to
help-echo, for example).

When that is done, normal redisplay could be used to draw the
mouse-highlight, but it would have to be extended to use mouse-face
for part of the text, which it currently doesn't.  Also, the logic
determining which parts of a buffer/window are to be redisplayed would
have to be extended somehow so that the highlighted region is
displayed despite the fact that there have been no buffer changes.

Re: signal handling bogosities

[Miles Bader]

Gerd Moellmann <gerd.moellmann@t-online.de> writes:
> My feeling is that the cost of restructuring the code to use an event
> loop could be pretty high, but I've never investigated this very
> deeply because Richard thought the current way of doing things is
> good, and an event loop is an abomination :).  There were lots of
> other things to do anyway, so I didn't pursue this further.
> 
> Specifically for mouse-highlighting there may be a cheaper solution,
> though.  IIRC, I once talked with Stefan Monnier about generating
> mouse-highlight input events for mouse highlights instead of doing the
> display directly when handling the mouse movement event (analogous to
> help-echo, for example).
> 
> When that is done, normal redisplay could be used to draw the
> mouse-highlight, but it would have to be extended to use mouse-face
> for part of the text, which it currently doesn't.  Also, the logic
> determining which parts of a buffer/window are to be redisplayed would
> have to be extended somehow so that the highlighted region is
> displayed despite the fact that there have been no buffer changes.

Perhaps I'm confused, but why can't the existing code that runs from the
signal handler just be called from the event loop instead, at least as
an easy first-step?

For instance, if the signal handler currently looks like:

   void signal_handler (...)
   {
     if (some_test)
       do_mouse_stuff (mouse_info);
     else if (some_other_test)
       do_exposure_stuff (other info);
   }

change it to be like:

   void signal_handler (...)
   {
     if (some_test)
       queue_mouse_event (mouse_info);
     else if (some_other_test)
       queue_exposure_event (exposure_info);
   }

   void event_loop_function (...)
   {
      while (event in event loop)
        {
          ...
          if (event->type == mouse_event)
            do_mouse_stuff (event->mouse_info)
          else if (event->type == exposure_event)
            do_exposure_stuff (event->exposure_info)
          ...
        }
   }

In other words, re-use as much of the existing code as possible, but
change the place where it's called.

My (vague) reasoning is that if it currently can be called from a
_signal handler_, which is possibly the worst possible case, then the
code must be pretty safe to call from just about anywhere -- so why not
the event loop?

Thanks,

-Miles
-- 
I'm beginning to think that life is just one long Yoko Ono album; no rhyme
or reason, just a lot of incoherent shrieks and then it's over.  --Ian Wolff

Re: signal handling bogosities

[Gerd Moellmann]

Miles Bader <miles@lsi.nec.co.jp> writes:

> Perhaps I'm confused, but why can't the existing code that runs from the
> signal handler just be called from the event loop instead, at least as
> an easy first-step?
> 
> For instance, if the signal handler currently looks like:
> 
>    void signal_handler (...)
>    {
>      if (some_test)
>        do_mouse_stuff (mouse_info);
>      else if (some_other_test)
>        do_exposure_stuff (other info);
>    }
> 
> change it to be like:
> 
>    void signal_handler (...)
>    {
>      if (some_test)
>        queue_mouse_event (mouse_info);
>      else if (some_other_test)
>        queue_exposure_event (exposure_info);
>    }
> 
>    void event_loop_function (...)
>    {
>       while (event in event loop)
>         {
>           ...
>           if (event->type == mouse_event)
>             do_mouse_stuff (event->mouse_info)
>           else if (event->type == exposure_event)
>             do_exposure_stuff (event->exposure_info)
>           ...
>         }
>    }
> 
> In other words, re-use as much of the existing code as possible, but
> change the place where it's called.

What I was thinking about as "event loop" is a toolkit's event loop,
like XtAppMainLoop etc. for Xt, for instance.

I must admit that I never thought about using a home-brewed event
loop, so I can't say much about what that entails, sorry.

Re: signal handling bogosities

[Gerd Moellmann]

storm@cua.dk (Kim F. Storm) writes:

> gerd.moellmann@t-online.de (Gerd Moellmann) writes:
> 
> > 
> > I must admit that I never thought about using a home-brewed event
> > loop, so I can't say much about what that entails, sorry.
> 
> But emacs already has its own home-brewed event loop in
> kbd_buffer_get_event:

Well, I don't understand what the "but" refers to :).

[...]

> Adding DELAYED_MOUSE_EVENT and DELAYED_EXPOSURE_EVENT to
> that list doesn't seem to be too difficult??

If you mean mouse highlighting with DELAYED_MOUSE_EVENT, that's
essentially what I talked about previously.

For handling other events likewise---as I said, I haven't analyzed
that.  For example, seeing exposures mentioned, I don't know if it
would be acceptable to not redraw anything while Emacs is busy.  Maybe
it is, maybe it isn't.

Someone will have to analyze all the consequences of a new
implementation for all kinds of events.

Re: signal handling bogosities

[Kim F. Storm]

gerd.moellmann@t-online.de (Gerd Moellmann) writes:

> 
> I must admit that I never thought about using a home-brewed event
> loop, so I can't say much about what that entails, sorry.

But emacs already has its own home-brewed event loop in
kbd_buffer_get_event:

      if (event->kind == SELECTION_REQUEST_EVENT)
      else if (event->kind == SELECTION_CLEAR_EVENT)
      else if (event->kind == DELETE_WINDOW_EVENT)
      else if (event->kind == ICONIFY_EVENT)
      else if (event->kind == DEICONIFY_EVENT)
      else if (event->kind == BUFFER_SWITCH_EVENT)
      else if (event->kind == MENU_BAR_ACTIVATE_EVENT)
        ...

Adding DELAYED_MOUSE_EVENT and DELAYED_EXPOSURE_EVENT to
that list doesn't seem to be too difficult??


-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: signal handling bogosities

[Richard Stallman]

    That signal results in `note_mouse_movement', and then
    `note_mouse_highlight' being called:

       #11 0x080b2345 in note_mouse_highlight (f=0x850aa18, x=184, y=260)
	   at /usr/local/src/emacs/src/xterm.c:7407
       #12 0x080b162e in note_mouse_movement (frame=0x850aa18, event=0xbffd1064)
	   at /usr/local/src/emacs/src/xterm.c:6893
       #13 0x080b5f05 in handle_one_xevent (dpyinfo=0x84f5490, eventp=0xbffd13ac, 
	   bufp_r=0xbffd1418, numcharsp=0xbffd141c, finish=0xbffd13a8)
	   at /usr/local/src/emacs/src/xterm.c:11291

    note_mouse_highlight then tries to figure out the proper mouse-face-id,
    which calls face realization, and if realize-face-filter-functions has
    a non-nil value, calls the lisp interpreter, and thus dies as seen.

I am surprised that the signal handler does face realization.  I would
have expected redisplay ought to do that job.  When the signal handler
runs, it should just look up the data that was computed by redisplay.

In the past, face realization did not evaluate any Lisp code, so
calling it from the signal handler was not a bug.  It may have been
bad design though.

    display the mouse face, and in other branches of the code the whole
    redisplay engine seems to be invoked, for exposure events (I don't know
    whether that can result in lisp code being called, but it seems as if it
    could -- given the complexity of redisplay, it's kind of hard to tell).

That seems bizarre too.  Can you please show me what you have learned
about this?

      How hard would be to
    restructure things to just queue this stuff for an event-loop outside
    the signal handler to handle?

That design has a serious drawback: the screen won't refresh while Emacs
is running.

The design idea used to be that the signal handler would update the
screen in a simple way based on tables that were computed in advance
by redisplay.  This avoided the problem we have now, and would
redisplay immediately even when Emacs is running.  Can we make it work
this way again?

Gerd wrote:

    Specifically for mouse-highlighting there may be a cheaper solution,
    though.  IIRC, I once talked with Stefan Monnier about generating
    mouse-highlight input events for mouse highlights instead of doing the
    display directly when handling the mouse movement event (analogous to
    help-echo, for example).

If we handle mouse highlighting by generating input events to do the
work at main program level, then the highlighting won't change when
you move the mouse while Emacs is running a Lisp program.  Is that
acceptable?

It is not as bad as failing to refresh the screen at all while
a Lisp program is running, but it is still somewhat undesirable.

Re: signal handling bogosities

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Date: Fri, 20 Dec 2002 12:12:24 -0500
> 
> If we handle mouse highlighting by generating input events to do the
> work at main program level, then the highlighting won't change when
> you move the mouse while Emacs is running a Lisp program.  Is that
> acceptable?

I think it might be acceptable if Emacs displays the busy cursor (as
it does by default, IIRC).  The cursor chape tells the user that
Emacs is busy.

Re: signal handling bogosities

[Alex Schroeder]

Richard Stallman <rms@gnu.org> writes:

> If we handle mouse highlighting by generating input events to do the
> work at main program level, then the highlighting won't change when
> you move the mouse while Emacs is running a Lisp program.  Is that
> acceptable?

>From a user perspective, I think that is acceptable.  Sure, currently
most programs use a second thread for their GUI, so eventhough they
are busy, you can open menus -- but when it gets to doing something,
they are just as bound by the event queue as Emacs is -- you can open
the menu, look at it, click on it, but things only happen when the
previous job is done.  Since users cannot do anything anyway when
Emacs is busy, I think it is not a big plus to have highlighting
working.  Loosing that, therefore, is not a problem.

Alex.

Re: signal handling bogosities

[Miles Bader]

On Fri, Dec 20, 2002 at 12:12:24PM -0500, Richard Stallman wrote:
> If we handle mouse highlighting by generating input events to do the
> work at main program level, then the highlighting won't change when
> you move the mouse while Emacs is running a Lisp program.  Is that
> acceptable?

In fact I find it confusing (as a user) that it updates mouse-faces almost
always, but most things only when it's `ready'.  Since you can't actually
_do_ anything until emacs is ready to accept input, it seems much better to
have mouse-faces respond similarly to the way the rest of emacs does.

Anyway, that's my take.

-Miles
-- 
97% of everything is grunge

Re: signal handling bogosities

[Richard Stallman]

    In fact I find it confusing (as a user) that it updates mouse-faces almost
    always, but most things only when it's `ready'.

Emacs won't let you *change* text in the buffer until it is `ready',
and of course they don't update until they change.  By contrast, the
locus of mouse highlighting does change, whenever you move the mouse.

Re: signal handling bogosities

[Alex Schroeder]

Richard Stallman <rms@gnu.org> writes:

>     In fact I find it confusing (as a user) that it updates mouse-faces almost
>     always, but most things only when it's `ready'.
>
> Emacs won't let you *change* text in the buffer until it is `ready',
> and of course they don't update until they change.  By contrast, the
> locus of mouse highlighting does change, whenever you move the mouse.

True, but the question is "What for?"  Here is my interpretation:  The
point of highlighting certain areas when the mouse pointer is over
that particular area is to convey some information.  Usually the
information is "Use the second mouse button to do something".  But in
this case the user cannot click the second mouse button to do
something.  Emacs is already doing something else.  So in this
particular case, the information conveyed is wrong.

I know this just repeats what others have said, but I just wanted to
prevent that Miles' (?) argument is discarded just because he used the
wording "updates mouse-faces".

Alex.

Re: signal handling bogosities

[Miles Bader]

On Sat, Dec 21, 2002 at 03:26:32PM -0500, Richard Stallman wrote:
>     In fact I find it confusing (as a user) that it updates mouse-faces
>     almost always, but most things only when it's `ready'.
> 
> Emacs won't let you *change* text in the buffer until it is `ready',
> and of course they don't update until they change.  By contrast, the
> locus of mouse highlighting does change, whenever you move the mouse.

I'm sure there's a way you can think of it so that it `makes sense'
(and of course I understand technically why it happens the way it does).

None-the-less, I really do find it confusing in practice because seeing the
buffer contents apparently change makes it _feel_ like emacs is ready do so
something (even though it's not), and I'm subsequently surprised when I
try to do something else and can't.

Consider another apparently similar case:  In X (unlike some other window
systems), you can move, resize, and iconify windows even when the underlying
applications aren't ready to respond (and so can't redraw).  In contrast with
emacs mouse-faces, this _feels_ right to me.

I guess the only way I can explain the difference is that in X the window
frame title bar visually appear to be a `wrapper,' and I can easily think of
them as being a completely separate layer and thus follow different rules of
interaction.  In emacs, mouse highlighting is visually part of the buffer
contents, and so it's harder to think it as being somehow separate.
[However, I think it _would_ seem natural if one could move emacs-window
boundaries without being to actually interact with the buffer, because
they're visually distinct layers]

Anyway, those are my thoughts.

-Miles

-- 
`The suburb is an obsolete and contradictory form of human settlement'

Re: signal handling bogosities

[Miles Bader]

On Fri, Dec 20, 2002 at 12:12:24PM -0500, Richard Stallman wrote:
> I am surprised that the signal handler does face realization.  I would
> have expected redisplay ought to do that job.  When the signal handler
> runs, it should just look up the data that was computed by redisplay.

The mouse-face is merged with whatever underlying faces are in the buffer in
the highlighted region, so you can't just have one precomputed mouse-face.

I suppose you could have redisplay notice which regions might be highlighted,
and pre-cache the corresponding mouse-face/buffer-face combination so that it
doesn't happen at highlighting time, but I don't know how easy this would be
(and if the face cache gets flushed at the wrong toime, you have a problem!).

-Miles
-- 
Come now, if we were really planning to harm you, would we be waiting here, 
 beside the path, in the very darkest part of the forest?

Re: signal handling bogosities

[Richard Stallman]

    True, but the question is "What for?"  Here is my interpretation:  The
    point of highlighting certain areas when the mouse pointer is over
    that particular area is to convey some information.  Usually the
    information is "Use the second mouse button to do something".  But in
    this case the user cannot click the second mouse button to do
    something.

You can click the second mouse button then--the request won't
be processed immediately, but it will be processed.

(If your argument is valid, the real conclusion is that Emacs should
turn off the highlighting, not leave the highlighting in the place
where the mouse WAS.)

Re: signal handling bogosities

[Richard Stallman]

    The mouse-face is merged with whatever underlying faces are in the buffer in
    the highlighted region, so you can't just have one precomputed mouse-face.

We could have a precomputed mouse face for each glyph.

Re: signal handling bogosities

[Michael Livshin]

gerd.moellmann@t-online.de (Gerd Moellmann) writes:

> I must admit that I never thought about using a home-brewed event
> loop, so I can't say much about what that entails, sorry.

FWIW, I believe Xemacs uses a home-brewed event loop.  which allows
it to support such things as opening both X and text-terminal frames
in the same Emacs instance, for example.  very nifty.

-- 
I think people have a moral obligation to spell "deontic" correctly.
                                   -- Erik Naggum, in comp.lang.lisp

Re: signal handling bogosities

[Richard Stallman]

    FWIW, I believe Xemacs uses a home-brewed event loop.  which allows
    it to support such things as opening both X and text-terminal frames
    in the same Emacs instance, for example.  very nifty.

The XEmacs developers told me 10 years ago that XEmacs used an
inside-out structure, where Xt implements the event loop and calls
Emacs to handle each events.  That unnatural structure makes it
impossible to write your own loop in Lisp.  I rejected it.

They told me that it was impossible to handle Xt with a natural
structure, where the event loop uses the toolkit as a subroutine, but
we did it.  (Actually I think Paul Reilly did it.)

I will not accept that unnatural structure now, any more than I did 10
years ago.  However, I won't reject all possible changes in the event
loop.  It might be useful to rewrite the event loop in Lisp (keeping
its present natural structure).

Re: signal handling bogosities

[Jan D.]

> 
>     FWIW, I believe Xemacs uses a home-brewed event loop.  which allows
>     it to support such things as opening both X and text-terminal frames
>     in the same Emacs instance, for example.  very nifty.
> 
> The XEmacs developers told me 10 years ago that XEmacs used an
> inside-out structure, where Xt implements the event loop and calls
> Emacs to handle each events.  That unnatural structure makes it
> impossible to write your own loop in Lisp.  I rejected it.

One could argue that for a GUI application the XEmacs approach is the
natural loop :-)

> They told me that it was impossible to handle Xt with a natural
> structure, where the event loop uses the toolkit as a subroutine, but
> we did it.  (Actually I think Paul Reilly did it.)

But not without problems as this discussion shows.  Also, there are some
code just to overcome these problems (timers for example) that feels
like a kludge.  I see that Emacs does some polling when running under
X, there is a timeout for about half a second for each select call.
I don't know why, but I guess it is related.  This makes it hard
to debug events, if nothing else.

I read a paper about event loops on the net some time ago (no URL, sorry),
and it described the problems of integrating several event models.
Say you have some GUI toolkit, perhaps CORBA, some database access
toolkit, and a custom event loop for your application.  Trying to
integrate these into one loop is never easy since all these toolkits usually
assume you run their event loop and nothing else.  Some are more integration-
friendly than others (X/Xt is very friendly, GTK is very unfriendly).
Threads to the rescue, but that is not always that easy either.

> I will not accept that unnatural structure now, any more than I did 10
> years ago.  However, I won't reject all possible changes in the event
> loop.  It might be useful to rewrite the event loop in Lisp (keeping
> its present natural structure).

I haven't looked at this in detail, but it seems to me that a lot could be
gained if Emacs could wait for events in some toolkit specific routine,
like XtAppNextEvent for Xt.  Now it looks to me it does a select for
the X connection file descriptor.  The difference is that if we use
a toolkit routine, timers, signal handlers and idle callbacks and
possible other stuff the toolkit wants to do, gets handled normally.

Has this been considered?  It doesn't solve the redrawing while executing
lisp, but helps a bit.

	Jan D.

Re: signal handling bogosities

[Richard Stallman]

    > The XEmacs developers told me 10 years ago that XEmacs used an
    > inside-out structure, where Xt implements the event loop and calls
    > Emacs to handle each events.  That unnatural structure makes it
    > impossible to write your own loop in Lisp.  I rejected it.

    One could argue that for a GUI application the XEmacs approach is the
    natural loop :-)

It prevents the Lisp code from being natural.  That is more important.
The natural structure for an event loop in Lisp is

  (while ...
    (let ((input (read-events-somehow)))
      (execute input)))

Any change in Emacs that would prevent the Lisp code from looking like
this has a major drawback.

    I haven't looked at this in detail, but it seems to me that a lot could be
    gained if Emacs could wait for events in some toolkit specific routine,
    like XtAppNextEvent for Xt.

Emacs needs to wait for input from various descriptors at the same
time, adn with a timeout.  If it is possible to do that with
XtAppNextEvent, then it is possible to use XtAppNextEvent.

Re: signal handling bogosities

[Jan D.]

> 
>     I haven't looked at this in detail, but it seems to me that a lot could be
>     gained if Emacs could wait for events in some toolkit specific routine,
>     like XtAppNextEvent for Xt.
> 
> Emacs needs to wait for input from various descriptors at the same
> time, adn with a timeout.  If it is possible to do that with
> XtAppNextEvent, then it is possible to use XtAppNextEvent.

Yes it is.  I shall do some experiments.

	Jan D.