From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: "Jan D." Newsgroups: gmane.emacs.devel Subject: Re: Core dumps in redisplay. Date: Fri, 4 Mar 2005 19:54:16 +0100 Message-ID: <5fc6e1563cda9518e92ea2832556bf46@swipnet.se> References: <7eee8e4a0b7241b67a0ae97e4923b908@swipnet.se> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1109963129 25026 80.91.229.2 (4 Mar 2005 19:05:29 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 4 Mar 2005 19:05:29 +0000 (UTC) Cc: Emacs Devel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Mar 04 20:05:28 2005 Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1D7I2g-0001zY-Jl for ged-emacs-devel@m.gmane.org; Fri, 04 Mar 2005 20:00:58 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1D7ILt-0005EL-UM for ged-emacs-devel@m.gmane.org; Fri, 04 Mar 2005 14:20:45 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1D7IK9-0004gK-5C for emacs-devel@gnu.org; Fri, 04 Mar 2005 14:18:57 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1D7IK0-0004cV-P3 for emacs-devel@gnu.org; Fri, 04 Mar 2005 14:18:49 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1D7IK0-0004aU-Ac for emacs-devel@gnu.org; Fri, 04 Mar 2005 14:18:48 -0500 Original-Received: from [195.54.107.70] (helo=mxfep01.bredband.com) by monty-python.gnu.org with esmtp (Exim 4.34) id 1D7Hwn-0005hR-PI; Fri, 04 Mar 2005 13:54:50 -0500 Original-Received: from coolsville.localdomain ([83.226.180.210] [83.226.180.210]) by mxfep01.bredband.com with ESMTP id <20050304185448.LPBI429.mxfep01.bredband.com@coolsville.localdomain>; Fri, 4 Mar 2005 19:54:48 +0100 In-Reply-To: Original-To: rms@gnu.org X-Mailer: Apple Mail (2.619.2) 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:34181 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:34181 2005-02-28 kl. 15.49 skrev Richard Stallman: > This sounds like normally only the main thread should ever be > touching > interrupt_input_blocked, unless we have a bug. Correct? So we > need > not think about how to synchronize accesses to the variable, but > rather make sure that no thread except the main thread will ever > run > code touching it. Correct? > > That is one coherent design plan. It may not be the only one. > > Meanwhile, operations carried out in another thread are somewhat like > operations carried out in a signal handler. So in some cases it may > be necessary for other threads to wait for interrupt_input_blocked to > be 0 before they do their work. I think this is only needed if the other threads will be executing Emacs code. For the case at hand (the Gnome file chooser backend), this is the case only for malloc and friends because Emacs inserts it hooks for malloc etc. > > And unless those threads have strictly higher priority than the main > thread, we have to worry about locking: how to prevent the main thread > from continuing and entering code that does BLOCK_INPUT while the > other thread is doing something that's supposed to be blocked by > BLOCK_INPUT. Signal handling with multiple threads is not portable and very tricky. If we could minimize the work done in signal handlers, preferrably just setting a variable or two, thing would be simpler. But a mutex lock/unlock in BLOCK/UNBLOCK_INPUT is the obvious initial approach. Jan D.