From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: Core dumps in redisplay. Date: Sun, 27 Feb 2005 21:21:38 +0100 Message-ID: References: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1109536871 29773 80.91.229.2 (27 Feb 2005 20:41:11 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 27 Feb 2005 20:41:11 +0000 (UTC) Cc: Emacs Devel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Feb 27 21:41:11 2005 Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1D5VCL-0005Sy-RU for ged-emacs-devel@m.gmane.org; Sun, 27 Feb 2005 21:39:30 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1D5VUZ-0005dv-Ek for ged-emacs-devel@m.gmane.org; Sun, 27 Feb 2005 15:58:19 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1D5VTI-0004p8-2F for emacs-devel@gnu.org; Sun, 27 Feb 2005 15:57:00 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1D5VPa-0002kc-Pu for emacs-devel@gnu.org; Sun, 27 Feb 2005 15:53:11 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1D5VPN-0002Og-Kt for emacs-devel@gnu.org; Sun, 27 Feb 2005 15:52:57 -0500 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1D5Uv6-0007l7-Dq for emacs-devel@gnu.org; Sun, 27 Feb 2005 15:21:40 -0500 Original-Received: from localhost ([127.0.0.1] helo=lola.goethe.zz) by fencepost.gnu.org with esmtp (Exim 4.34) id 1D5Uv5-0006LO-Ot; Sun, 27 Feb 2005 15:21:40 -0500 Original-To: "Jan D." In-Reply-To: (Jan D.'s message of "Sun, 27 Feb 2005 21:08:10 +0100") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org X-MailScanner-To: ged-emacs-devel@m.gmane.org Xref: main.gmane.org gmane.emacs.devel:33880 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:33880 "Jan D." writes: >> Also with regard to the other report you answered (where I was wrong): >> I might well be mistaken. I am just trying to get a hold of why Emacs >> keeps crashing on me. It appears, anyway, that something seriously >> elusive is going on here. I'll probably have to implement some kind >> of trace buffering for interrupt_input_block in order to get a hold of >> what is happening here. >> >> I already disassembled stuff because I thought the compiler might be >> at fault. Maybe I should also try without optimization. > > > If you configured with GTK, there is a possibility that multiple > threads are updating interrupt_input_block. I've tried to handle that > situation, but bugs may of course still remain. How did you try to handle it? Basically, we have the following accesses to interrupt_input_blocked: BLOCK_INPUT increases it UNBLOCK_INPUT decreases it TOTALLY_UNBLOCK_INPUT resets it throws reset it to the state at the time of the catch The last two options would behave really badly in the presence of multithreading. There must only be one thread touching interrupt_input_blocked, or we get into trouble. I don't see that we can sensibly handle the case "reset to state at the time of the catch" in any manner with two threads accessing the variable. We need one variable per thread then, and the input is blocked if either variable is nonzero. Only a per-thread variable can be reset to a meaningful value. Could you elaborate on what happens here in parallel threads? I can't imagine that one can execute Lisp sanely in two threads, so one thread would be likely C-only? Why would that thread have to meddle with interrupt_input_blocked at all? -- David Kastrup, Kriemhildstr. 15, 44793 Bochum