From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Richard Stallman Newsgroups: gmane.emacs.devel Subject: Re: Core dumps in redisplay. Date: Mon, 28 Feb 2005 09:49:02 -0500 Message-ID: References: <7eee8e4a0b7241b67a0ae97e4923b908@swipnet.se> Reply-To: rms@gnu.org NNTP-Posting-Host: main.gmane.org X-Trace: sea.gmane.org 1109602768 9033 80.91.229.2 (28 Feb 2005 14:59:28 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 28 Feb 2005 14:59:28 +0000 (UTC) Cc: jan.h.d@swipnet.se, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Feb 28 15:59:27 2005 Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1D5mE3-0001Ok-DB for ged-emacs-devel@m.gmane.org; Mon, 28 Feb 2005 15:50:24 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1D5mWQ-0001ir-Jl for ged-emacs-devel@m.gmane.org; Mon, 28 Feb 2005 10:09:22 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1D5mR1-0005pS-Or for emacs-devel@gnu.org; Mon, 28 Feb 2005 10:03:47 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1D5mR0-0005oH-H2 for emacs-devel@gnu.org; Mon, 28 Feb 2005 10:03:46 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1D5mR0-0005nH-2z for emacs-devel@gnu.org; Mon, 28 Feb 2005 10:03:46 -0500 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1D5mCk-0001me-Th for emacs-devel@gnu.org; Mon, 28 Feb 2005 09:49:03 -0500 Original-Received: from rms by fencepost.gnu.org with local (Exim 4.34) id 1D5mCk-00040t-9g; Mon, 28 Feb 2005 09:49:02 -0500 Original-To: David Kastrup In-reply-to: (message from David Kastrup on Sun, 27 Feb 2005 22:28:41 +0100) 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:33928 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:33928 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. 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.