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 09:19:13 +0200 Message-ID: <44E95E71.30203@swipnet.se> References: <87psevdhpc.fsf-monnier+emacs@gnu.org> <44E88FCA.5050705@swipnet.se> <44E9503E.7030609@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 1156144782 28375 80.91.229.2 (21 Aug 2006 07:19:42 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 21 Aug 2006 07:19:42 +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 09:19:40 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 1GF44O-0006Hu-Lh for ged-emacs-devel@m.gmane.org; Mon, 21 Aug 2006 09:19:36 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GF44N-0003DF-Tn for ged-emacs-devel@m.gmane.org; Mon, 21 Aug 2006 03:19:35 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1GF448-0003BF-Og for emacs-devel@gnu.org; Mon, 21 Aug 2006 03:19:20 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1GF446-000394-Mh for emacs-devel@gnu.org; Mon, 21 Aug 2006 03:19:20 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GF446-00038s-DR for emacs-devel@gnu.org; Mon, 21 Aug 2006 03:19:18 -0400 Original-Received: from [81.228.9.179] (helo=av6-1-sn3.vrr.skanova.net) by monty-python.gnu.org with esmtp (Exim 4.52) id 1GF4BQ-0001n5-Mn for emacs-devel@gnu.org; Mon, 21 Aug 2006 03:26:53 -0400 Original-Received: by av6-1-sn3.vrr.skanova.net (Postfix, from userid 502) id A4F76380CD; Mon, 21 Aug 2006 09:19:16 +0200 (CEST) Original-Received: from smtp3-2-sn3.vrr.skanova.net (smtp3-2-sn3.vrr.skanova.net [81.228.9.102]) by av6-1-sn3.vrr.skanova.net (Postfix) with ESMTP id 9671737EA0; Mon, 21 Aug 2006 09:19:16 +0200 (CEST) Original-Received: from coolsville.localdomain (81-235-205-204-no59.tbcn.telia.com [81.235.205.204]) by smtp3-2-sn3.vrr.skanova.net (Postfix) with ESMTP id E061D37E4C; Mon, 21 Aug 2006 09:19: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:58592 Archived-At: YAMAMOTO Mitsuharu skrev: >>>>>> On Mon, 21 Aug 2006 08:18:38 +0200, Jan Dj=E4rv said: >=20 >> I don't like it, because it assumes things are "probably OK" to run >> in the signal handler (i.e. pthread_mutex_lock/unlock). I still >> think it might hang if a Gnome thread is in mutex_lock and a signal >> arrives and then the signal handler also enters mutex_lock. >=20 > Does it mean the quote from IEEE Std 1003.1 did not convince you? In a way, but not the same way you interpret it :-). The quoute is: "All functions not in the above table are considered to be unsafe with respect to signals. In the presence of signals, all functions defined by this volume of IEEE Std 1003.1-2001 shall behave as defined when called from or interrupted by a signal-catching function, with a single exception: when a signal interrupts an unsafe function and the signal-catching function calls an unsafe function, the behavior is undefined." Read the single exception: "when a signal interrupts an unsafe function and the signal-catching function calls an unsafe function, the behavior is undefined." This is exactly what happens if a Gnome thread enters pthread_lock/unlock= and=20 a signal arrives and the signal handler later also calls pthread_lock/unl= ock.=20 This was the original problem. >=20 >> It is one assumtion against another, neither suggestion is without >> flaws (we need SYNC_INPUT for that). >=20 > No assumption is needed to say that the current code leads to a > problem under a certain scenario. >=20 No, but in the presense of signal handlers executing malloc, there is no=20 scenario that is safe. Your suggestion also has undefined behaviour acco= ding=20 to the quote from the standard. The one currently implemented has a race= =20 condition. > Suppose that we abandon emacs_blocked_malloc and so on when > HAVE_GTK_AND_PTHREAD is defined. I think it is as safe as other > non-GNU-malloc systems where emacs_blocked_malloc and so on are not > used, provided that malloc-related functions are thread-safe. What do > you think about that? This whole workaround with mutexes and blocks started because Emacs hange= d on=20 some system, I'm not sure if it was a GNU/Linux system or some kind of BS= D=20 variant. So I don't think we should go back, the old problem happend eve= ry=20 time the file selection box was opened on a Gnome system. Jan D.