From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: =?ISO-8859-1?Q?Jan_Dj=E4rv?= Newsgroups: gmane.emacs.devel Subject: Re: why "in_sighandler"? Date: Mon, 21 Aug 2006 10:46:36 +0200 Message-ID: <44E972EC.8000903@swipnet.se> References: <87psevdhpc.fsf-monnier+emacs@gnu.org> <44E88FCA.5050705@swipnet.se> <44E9503E.7030609@swipnet.se> <44E95E71.30203@swipnet.se> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-Trace: sea.gmane.org 1156150070 11156 80.91.229.2 (21 Aug 2006 08:47:50 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 21 Aug 2006 08:47:50 +0000 (UTC) Cc: Stefan Monnier , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Aug 21 10:47:48 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1GF5Rd-0008EF-9i for ged-emacs-devel@m.gmane.org; Mon, 21 Aug 2006 10:47:41 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GF5Rc-0000YR-RS for ged-emacs-devel@m.gmane.org; Mon, 21 Aug 2006 04:47:40 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1GF5RI-0000Um-GT for emacs-devel@gnu.org; Mon, 21 Aug 2006 04:47:20 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1GF5RG-0000Sv-9I for emacs-devel@gnu.org; Mon, 21 Aug 2006 04:47:19 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GF5RG-0000Se-3f for emacs-devel@gnu.org; Mon, 21 Aug 2006 04:47:18 -0400 Original-Received: from [81.228.9.181] (helo=av7-1-sn3.vrr.skanova.net) by monty-python.gnu.org with esmtp (Exim 4.52) id 1GF5Yb-0006gv-H2 for emacs-devel@gnu.org; Mon, 21 Aug 2006 04:54:53 -0400 Original-Received: by av7-1-sn3.vrr.skanova.net (Postfix, from userid 502) id 26128382BB; Mon, 21 Aug 2006 10:47:12 +0200 (CEST) Original-Received: from smtp3-1-sn3.vrr.skanova.net (smtp3-1-sn3.vrr.skanova.net [81.228.9.101]) by av7-1-sn3.vrr.skanova.net (Postfix) with ESMTP id 16FC437F60; Mon, 21 Aug 2006 10:47:12 +0200 (CEST) Original-Received: from coolsville.localdomain (81-235-205-204-no59.tbcn.telia.com [81.235.205.204]) by smtp3-1-sn3.vrr.skanova.net (Postfix) with ESMTP id C00F337E48; Mon, 21 Aug 2006 10:47:15 +0200 (CEST) User-Agent: Thunderbird 1.5.0.5 (X11/20060808) Original-To: YAMAMOTO Mitsuharu In-Reply-To: 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:58595 Archived-At: YAMAMOTO Mitsuharu skrev: >>>>>> On Mon, 21 Aug 2006 09:19:13 +0200, Jan Dj=E4rv said: >=20 >> Read the single exception: "when a signal interrupts an unsafe >> function and the signal-catching function calls an unsafe function, >> the behavior is undefined." >=20 > So, you interpret that ``what are interrupted by a signal'' are all > the functions in execution on the whole threads in the process, not > just a single function in execution on the thread that the signal is > delivered to? I don't think that is a natural interpretation. I don't see the line "what are interrupted by a signal" in the quote, so = I'm=20 not sure what you mean. My interpretation is that it is unsafe to call lock/unlock from a thread = and=20 from a signal handler at the same time, if they operate on the same mutex= .=20 That is what the original hang was all about. >=20 >> No, but in the presense of signal handlers executing malloc, there >> is no scenario that is safe. Your suggestion also has undefined >> behaviour accoding to the quote from the standard. >=20 > As I said earlier, the current Emacs implementation calls malloc > within a signal handler with the help of BLOCK_INPUT relying on the > assumption that it is safe unless the signal interrupted > malloc-related functions. But this only works for the Emacs main thread, not the Gnome threads. Jan D.