bug#65193: 29.1.50; SET_FRAME_ICONIFIED can cause Lisp evaluation inside read_socket_hook.

[YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>]

On Thu, 10 Aug 2023 17:26:00 +0900,
Po Lu wrote:
> 
> YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes:
> 
> > SET_FRAME_ICONIFIED has a call to gui_consider_frame_title and it can
> > cause Lisp evaluation if icon-title-format or frame-title-format
> > contains (:eval FORM).  This is problematic because
> > SET_FRAME_ICONIFIED can be called inside read_socket_hook.
> >
> > The call to gui_consider_frame_title was introduced by the following
> > change:
> 
> What practical problems have resulted from this change?

To my understanding, the Lisp evaluator is not reentrant, and thus
Lisp evaluation inside read_socket_hook, which can be called from
fairly arbitrary places via unblock_input/maybe_quit, causes
hard-to-reproduce, spontaneous crashes.

> There are already several situations under which Lisp can be called
> inside read_socket_hook.

That's really surprising.  I've once heard we shouldn't do that.  Is
that changed?

> And in principle, anything that performs GC can in turn call
> finalizers that subsequently run Lisp.

My understanding is that GC can only be triggered by eval_sub or
Ffuncall calls (except explicit garbage_collect calls), but not by
Lisp object allocations, for example.  Avoiding Lisp evaluation inside
read_socket_hook also means avoiding GC inside read_socket_hook.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp