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

[Eli Zaretskii]

> Date: Tue, 27 Dec 2016 10:44:24 +0000
> From: Alan Third <alan@idiocy.org>
> Cc: charles@aurox.ch, 25265@debbugs.gnu.org
> 
> OK, I’ve ended up just using printf and it looks like in this thread
> current_thread is null.

This happens in only one place: run_thread, after a thread exits.  And
yes, it's a bad idea to rely on current_thread being non-NULL in code
that is run when other threads could be running.

More generally, this means calling unbind_to, i.e. unwinding the Lisp
stack, is not going to work in this context at all, because that in
effect runs Lisp when more than one thread could run their code.

> > > >     [NSApp run];
> > > > 
> > > > Can this part and its surrounding code be made thread-safe?
> > > 
> > > I think this particular method call has to be done *only* from the
> > > main thread. I imagine that could be a problem.
> > 
> > It could be a problem, yes.  But what does this do, exactly, and why
> > does it need to be called as part of ns_select?
> 
> It runs an event loop that picks up all GUI events and then dispatches
> them. It’s part of NextStep. It’s unclear to me why it’s run in
> ns_select, but presumably it’s because it needs to be run somewhere
> and whoever wrote it thought that was a good place.
> 
> If we need to, I expect we could move it to its own thread. That seems
> to be a known pattern in the GNUStep/Cocoa world.

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?

> I’m pretty sure that Emacs doesn’t even use ns_select when it’s run
> in the terminal, though.

Actually, I think it has to use ns_select, because subprocesses are
still supported on a text terminal, and reading their output calls
ns_select.  Likewise network connections.