Re: bug#60144: 30.0.50; PGTK Emacs crashes after signal

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> But AFAIK it is _always_ safe for unblock_input to signal.  When do
> you think it isn't?

In almost all of the helper functions where it is called:
tear_down_x_back_buffer, set_up_x_back_buffer, et cetera.

Otherwise, why does it not call maybe_quit after reading pending events?
If it's safe to signal from unblock_input, then there should be no point
in delaying quitting until the next time maybe_quit is called?

> ??? w32_read_socket runs in the Lisp (a.k.a. "main") thread.  So it is
> safe for any code it calls it to signal errors and do anything else
> it's safe to do for the Lisp machine.

It can run from unblock_input.  Basically any code where it is unsafe to
signal (and there is a lot) calling unblock_input is put at risk.  Think
of all the callers of xmalloc without input blocked.

> You cannot request that.  note_mouse_highlight examines properties,
> and that can always signal, because properties are Lisp creatures and
> can invoke Lisp.

Could you please explain how?

> We gradually removed all those unsafe parts, and nowadays we only do
> the minimum in such contexts.  If unsafe processing of input is still
> with us, we should move to safer techniques.  That this unsafe code
> exists for such a long time is therefore not a justification for it to
> continue existing.
>
> Also, I think this unsafe processing of events only happens with
> GTK/PGTK; other X configurations call XTread_socket and
> handle_one_xevent from keyboard.c, in a "safe" context.

Non-local exits from handle_one_xevent are simply not safe.  That
function is not only called from XTread_socket, it is also called from
x_dispatch_event, which is called from various toolkit menus, including
inside the menu widget's own event loop.

> I didn't say we shouldn't process mouse movements.  I said that this
> processing should be limited to generating an Emacs input event and
> queuing it, will all the pertinent information for further processing.
> For example, note_mouse_highlight does just three things:
>
>   . redisplays portion of the window in a special face
>   . changes the way the cursor is drawn
>   . shows help-echo
>
> All of that can be done given an input event read by terminals
> read_socket_hook inside keyboard.c, provided that the information
> about the mouse move is stored in the input event.  There's
> absolutely no reason to produce the above 3 effects right where we are
> fed the raw X or GTK event from the window-system or the toolkit.

How would working with the mouse highlight work inside a popup menu,
then?  Keyboard events are not being read inside popup_get_selection.

> AFAIU, these two events will both be queued, and will both be
> processed, so there will be not "suck mouse highlight".

No, clear_mouse_face is absolutely safe to call synchronously, from the
likes of x_mouse_leave and the XI_Leave handlers.

In fact, it can be called from places where it is impossible to handle
keyboard events: popup dialogs and menus.

> So I still don't understand what is it that I'm missing that makes you
> say this safe processing of window-system events is impossible.

Just that I'm not confident in that.  I can't explain why but the mouse
highlight code is already tricky now, and something tells me moving it
to keyboard.c will make it even trickier.

And besides, note_mouse_highlight should not signal, regardless of
whether or not doing so is safe.  Otherwise, users' work could be
interrupted by simple mouse movement.

> Anyway, this bug report is not the proper place to discuss this.
> Please start a discussion on emacs-devel, and let's pick this up
> there.

Done.