GNU bug report logs - #25247
26.0.50; Concurrency crashes

Previous Next

Full log

Message #41 received at 25247 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ken Raeburn <raeburn <at> raeburn.org>
Cc: 25247 <at> debbugs.gnu.org, tino.calancha <at> gmail.com
Subject: Re: bug#25247: 26.0.50; Concurrency crashes with XLib
Date: Fri, 30 Dec 2016 10:37:12 +0200

> From: Ken Raeburn <raeburn <at> raeburn.org>
> Date: Fri, 30 Dec 2016 02:19:29 -0500
> Cc: Eli Zaretskii <eliz <at> gnu.org>,
>  25247 <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.