From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: YAMAMOTO Mitsuharu Newsgroups: gmane.emacs.devel Subject: Re: usr1-signal, usr2-signal, etc. Date: Tue, 12 Dec 2006 22:32:42 +0900 (JST) Message-ID: <20061212.223242.258196916.mituharu@math.s.chiba-u.ac.jp> References: <20061211.233142.146367996.mituharu@math.s.chiba-u.ac.jp> NNTP-Posting-Host: dough.gmane.org Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1165930503 3749 80.91.229.10 (12 Dec 2006 13:35:03 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 12 Dec 2006 13:35:03 +0000 (UTC) Cc: rms@gnu.org, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Dec 12 14:35:00 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by dough.gmane.org with esmtp (Exim 4.50) id 1Gu7ma-00011U-Uu for ged-emacs-devel@m.gmane.org; Tue, 12 Dec 2006 14:34:57 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Gu7ma-0002Li-CB for ged-emacs-devel@m.gmane.org; Tue, 12 Dec 2006 08:34:56 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Gu7ls-00023n-3E for emacs-devel@gnu.org; Tue, 12 Dec 2006 08:34:12 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Gu7lq-00023C-DK for emacs-devel@gnu.org; Tue, 12 Dec 2006 08:34:11 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Gu7lq-000235-70 for emacs-devel@gnu.org; Tue, 12 Dec 2006 08:34:10 -0500 Original-Received: from [133.82.132.2] (helo=mathmail.math.s.chiba-u.ac.jp) by monty-python.gnu.org with esmtp (Exim 4.52) id 1Gu7lo-0000UA-I7; Tue, 12 Dec 2006 08:34:09 -0500 Original-Received: from localhost (church [133.82.132.36]) by mathmail.math.s.chiba-u.ac.jp (Postfix) with ESMTP id C568A2CBA; Tue, 12 Dec 2006 22:33:42 +0900 (JST) Original-To: storm@cua.dk In-Reply-To: X-Mailer: Mew version 3.3 on Emacs 22.0 / Mule 5.0 (SAKAKI) 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 Xref: news.gmane.org gmane.emacs.devel:63624 Archived-At: >>>>> On Tue, 12 Dec 2006 10:47:09 +0100, storm@cua.dk (Kim F. Storm) said: > What if the signal handlers just increment a global counter (one for > each signal type), and the main loop in keyboard.c checked those > counters and added the pending signal events in the "safe context"? There're two problems I can think of with this approach. First, it will cause a race condition. I guess the global counters will be checked just before `select' is called in wait_reading_process_output. But if SIGUSR1 is delivered between the check of the counters and the call to `select', it does not interrupt `select' and will not be noticed until another input/signal becomes available or the timeout expires. This issue is discussed in [1]. Second, the current `select' emulation code in the Carbon port does not wait for signals, but only for window system events and process outputs via sockets. In principle, both of them can be solved by converting signal delivery to data delivery on a pipe or a UNIX domain socket as in [1]. But this will require not-so-small changes, and I fear this becomes another sit-for case. Is it possible to postpone this feature to after the release? YAMAMOTO Mitsuharu mituharu@math.s.chiba-u.ac.jp [1] Unix Network Programming, Volume 1: The Sockets Networking API, 3rd Edition, Chapter 20, Section 5.