bug#25247: 26.0.50; Concurrency crashes with XLib

[Eli Zaretskii <eliz@gnu.org>]

> From: Ken Raeburn <raeburn@raeburn.org>
> Date: Fri, 30 Dec 2016 02:19:29 -0500
> Cc: Eli Zaretskii <eliz@gnu.org>,
>  25247@debbugs.gnu.org
> 
> As for Eli’s comments about moving the locking code into xgselect.c, I think that’s going to be needed.  I’ve got a patch in my private repository from a while back, waiting for some cleanup, that started doing something like that, but didn’t cover the Mac ns_select version because I’m unfamiliar with that code.  The unblock_input code accesses global variables like interrupt_input_blocked and pending_signals, but it can be called from xg_select without holding the global lock.  I think I also hit a case where current_thread was null due to the exiting of the “current” Lisp thread, and something called via unblock_input tried to use it to access one of the now-per-Lisp-thread variables.

My view of this is that calling unblock_input might call
handle_async_input, which in effect (and sometimes literally) will run
Lisp.  So we cannot do that in places that can be run by more than one
thread.

I will try to push a change that moves global lock acquiring into
xgselect.c later today.

As for ns_select, it sounds like the situation there is much more
complex, see the discussion in bug#25265.

> +#ifdef THREADS_ENABLED

Please use "#if THREADS_ENABLED" instead.

Thanks.