bug#25265: make-thread crashes in OS X 10.6

[Eli Zaretskii]

> Date: Wed, 28 Dec 2016 19:36:33 +0000
> From: Alan Third <alan@idiocy.org>
> Cc: charles@aurox.ch, 25265@debbugs.gnu.org
> 
> > That's probably the only reasonable way.  But why does it use
> > record_unwind_protect and unbind_to in the first place?  What happens
> > if the user presses C-g while the event loop runs?
> 
> It was added in change 08f27aa39c498d34418c7420b33bf2db913827c3 which
> relates to bug 18345. Previously it was simply apploopnr--, but
> sometimes users would find themselves in a situation where that line
> was never run (hitting C‐g while the event loop runs?) so the next
> time ns_select (or ns_read_socket) ran it aborted. I take it unbind_to
> fixes that particular problem.
> 
> Is there a safer way of ensuring that apploopnr is decremented?

There could be, but I see that ns_select and ns_read_socket use it for
some kind of synchronization between them, which I don't really
understand, so I cannot answer that question.

> I’m slowly beginning to understand what’s going on in ns_select. It
> seems the idea is that it should detect both input on file descriptors
> (using pselect in the background), and NS events coming from [NSApp
> run].

What do "NS events" include?  Do they include, for example, keyboard
input?

Also, does C-g cause a signal or some other async event on NS, which
could potentially interrupt the [NSApp run] stuff?  Or could SIGIO do
that (does NS use SIGIO for input?)?

If nothing could interrupt/QUIT [NSApp run], then I don't really
understand why we have unwind_protect there.  The bug in question
cites some undisclosed Lisp for reproducing the problem, so I wonder
how could that cause [NSApp run] to be interrupted and longjmp to
higher level.

> There is another thread that runs in a loop (fd_handler), and when
> it’s signalled from ns_select, it runs pselect. At the same time
> ns_select sets up a timer, then it calls [NSApp run].

(I think ns_select only sets up a timer when there are no descriptors
to watch, to avoid waking up the fd_handler thread in that case.)

So this means there are 2 jobs to be done here: the pselect call and
the [NSApp run] call.

> If either the pselect thread, or the timer run out before any input is
> detected, they send a user defined event to the NSApp event loop so it
> ends.
> 
> Similarly if the pselect thread detects input it sends an event to the
> NSApp loop, which then ends.
> 
> If there’s NS input, it’s processed by the NSApp loop

Processed how?  Shouldn't Emacs be involved in this processing?  IOW,
these events should be read by Emacs, via the read_socket_hook.

> Whatever happens, the NSApp loop eventually returns control back to
> ns_select, which works out what happened by examining the last NS
> event and returns the relevant value.
> 
> I have my doubts this is thread safe.

It isn't.  Unless each Emacs application thread will have its own
fd_handler thread.

One possible solution might be to let only one thread, say the main
thread, to call [NSApp run].  The other threads, when they get into
ns_select, will behave as if Emacs runs in non-GUI mode, and will only
call pselect.  Not sure what this will mean from the POV of all
threads being equal (since the delicate dance between ns_select and
ns_read_socket is still unclear to me), but at least it might avoid
crashes and hangs.  Can you try something like that?

> The communication between ns_select and fd_handler is done by
> setting static variables and then running:
> 
>     c = 'g';
>     emacs_write_sig (selfds[1], &c, 1);
> 
> I don’t really know what that does. Sends something on an fd?

Yes.  I guess 'g' stands for GO and 's' stands for SUSPEND.  These are
commands to the fd_handler thread, or so it seems.

Thanks.