> On Nov 5, 2022, at 22:40, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> 
>>>    -  if (WINDOWP (echo_area_window) && ! NILP (call0 (intern ("ns-in-echo-area"))))
>>>    +  was_waiting_for_input = waiting_for_input;
>>>    +  waiting_for_input = false;
>>>    +  specbind (Qinhibit_quit, Qt);
>>>    +  if (WINDOWP (echo_area_window) && ! NILP (safe_call (true, 0, Qns_in_echo_area)))
>>> 
>>> I'm glad we found a way to make the code work, apparently, but
>>> Here we need a comment explaining why we do this gymnastic of
>>> `safe_call` + `inhibit_quit` + `waiting_for_input`.
>> 
>> That is done all over the place in the NS code.
> 
> Then why does it need to be hand-coded here?  If it's done all over the
> place, it should have its own `super_extra_safe_call` function or
> something, no?
> 
>> I don't really know why, you will have to ask its original authors for
>> that, but suffice it to say calling Lisp from
>> firstRectForCharacterRange (and also the menu bar update callbacks)
>> will otherwise crash upon Fsignal being called.
> 
> Yet I don't see anything in `ns-in-echo-area` which would call `signal`.
> I don't mean to say that we should not protect ourselves from the case
> where `ns-in-echo-area` calls `signal`, but that the above explanation
> doesn't seem to explain the problem we're currently facing.
> [ And `safe_call` should be sufficient to protect ourselves from
>  `signal`.  ]

I’m not super familiar with the signal mechanism, but here are some findings.  (Assume that `waiting_for_input` is correctly maintained.)  On certain occasions (which still remain unclear to me), the `Vthrow_on_input` path in `process_quit_flag` is taken.  The curious thing is that `safe_call` does not seem to catch that, and thus the control flow directly moves to somewhere above the Lisp call in `firstRectForCharacterRange`.  Is it intentional that `safe_call` does not catch throw_on_input?

(Also a correction: I guessed it could be related to threading at first. No, it’s not. It’s always the main thread.)