[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: bug#60144: 30.0.50; PGTK Emacs crashes after signal
From: |
Po Lu |
Subject: |
Re: bug#60144: 30.0.50; PGTK Emacs crashes after signal |
Date: |
Mon, 19 Dec 2022 09:56:40 +0800 |
User-agent: |
Gnus/5.13 (Gnus v5.13) |
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.
- Re: bug#60144: 30.0.50; PGTK Emacs crashes after signal,
Po Lu <=
- Re: bug#60144: 30.0.50; PGTK Emacs crashes after signal, Eli Zaretskii, 2022/12/19
- Re: bug#60144: 30.0.50; PGTK Emacs crashes after signal, Po Lu, 2022/12/19
- Re: bug#60144: 30.0.50; PGTK Emacs crashes after signal, Eli Zaretskii, 2022/12/20
- Re: bug#60144: 30.0.50; PGTK Emacs crashes after signal, Po Lu, 2022/12/20
- Re: bug#60144: 30.0.50; PGTK Emacs crashes after signal, Eli Zaretskii, 2022/12/21
- Re: bug#60144: 30.0.50; PGTK Emacs crashes after signal, Po Lu, 2022/12/21
- Re: bug#60144: 30.0.50; PGTK Emacs crashes after signal, Eli Zaretskii, 2022/12/22
- Re: bug#60144: 30.0.50; PGTK Emacs crashes after signal, Po Lu, 2022/12/22