bug#25247: 26.0.50; Concurrency crashes

[Ken Raeburn]

On Dec 22, 2016, at 12:28, Eli Zaretskii <eliz@gnu.org> wrote:

>> From: Tino Calancha <tino.calancha@gmail.com>
>> Date: Thu, 22 Dec 2016 19:20:21 +0900
>> 
>> 
>> 1)
>> Save a file /tmp/test.el with contains:
>> 
>> (defun mytest ()
>>  (dotimes (n 10)
>>    (message "[%d] Sleeping ..." n)
>>    (sleep-for 0.5))
>>  (message "End!")
>>  (sleep-for 1)
>>  (message nil))
>> 
>> (defun run-test ()
>>  (dotimes (_ 50)
>>    (make-thread #'mytest))
>>  (message "Number of threads %d" (length (all-threads))))
>> 
>> ;; (run-test)
>> 
>> 2)
>> emacs -Q -l /tmp/test.el
>> ;; Evaluate (run-test) in buffer *scratch*; keep using Emacs, for instance,
>> ;; split the window, and visit other buffers, or call (run-test) again:
>> C-x 3
>> C-x C-b
>> C-o <down> RET
>> ;; Sometimes Emacs crash or hangs.
> 
> Thanks.
> 
> It doesn't crash or hang here.  Which is not surprising, since the
> backtraces seem to indicate some issue with X11/xcb and threads.  Ken,
> could you take a look, please?  Are we violating some X11 protocols by
> calling redisplay from different threads?

The documentation for XInitThreads, mentioned in one of the error messages, 
says it needs to be called before any other Xlib functions if a single display 
object might be used concurrently from multiple threads.  I’m testing out a 
change, but thus far haven’t been able to reproduce any of the crashes even 
without the patch, although I did run into the unblock_input_to abort on the 
concurrency branch, with a similar test program from Elias Mårtenson.

Also, in looking into this, I found a couple vague references about how “it is 
known” that there are problems with the concurrency support in Xlib in some 
areas.  Unfortunately there were no details (not even clear if it was an Xlib 
problem or related to using Java classes that talk to Xlib in ways the 
developer might not fully control), and I’ll be busy the next few days.  I’ll 
try to find out more next week.  But if only one thread is talking to a given X 
display *at a time* (whether displays are assigned to specific threads, or 
locking is used, or only one thread uses X at all, or whatever), I haven’t seen 
anything so far that would suggest there would be any problem.

Ken