[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#25247: 26.0.50; Concurrency crashes with XLib

From: Eli Zaretskii
Subject: bug#25247: 26.0.50; Concurrency crashes with XLib
Date: Fri, 30 Dec 2016 10:37:12 +0200

> From: Ken Raeburn <address@hidden>
> Date: Fri, 30 Dec 2016 02:19:29 -0500
> Cc: Eli Zaretskii <address@hidden>,
>  address@hidden
> 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

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.


Please use "#if THREADS_ENABLED" instead.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]