Re: signal handling bogosities

[Gerd Moellmann]

Miles Bader <address@hidden> 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.