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: Tue, 22 Aug 2006 10:23:40 +0200 Message-ID: <44EABF0C.7000207@swipnet.se> References: <87psevdhpc.fsf-monnier+emacs@gnu.org> <44E88FCA.5050705@swipnet.se> <44E9503E.7030609@swipnet.se> <44E95E71.30203@swipnet.se> <44E972EC.8000903@swipnet.se> <44E999CE.3080403@swipnet.se> <44EAA67E.1060400@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 1156235070 15279 80.91.229.2 (22 Aug 2006 08:24:30 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 22 Aug 2006 08:24:30 +0000 (UTC) Cc: Stefan Monnier , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Aug 22 10:24:26 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 1GFRYW-0008Nl-Uv for ged-emacs-devel@m.gmane.org; Tue, 22 Aug 2006 10:24:17 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GFRYV-0003nH-SZ for ged-emacs-devel@m.gmane.org; Tue, 22 Aug 2006 04:24:15 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1GFRYH-0003lo-07 for emacs-devel@gnu.org; Tue, 22 Aug 2006 04:24:01 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1GFRYF-0003in-2U for emacs-devel@gnu.org; Tue, 22 Aug 2006 04:24:00 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GFRYE-0003iU-Tw for emacs-devel@gnu.org; Tue, 22 Aug 2006 04:23:58 -0400 Original-Received: from [81.228.8.179] (helo=av9-1-sn2.hy.skanova.net) by monty-python.gnu.org with esmtp (Exim 4.52) id 1GFRfm-0000Ma-Hc for emacs-devel@gnu.org; Tue, 22 Aug 2006 04:31:47 -0400 Original-Received: by av9-1-sn2.hy.skanova.net (Postfix, from userid 502) id 3B6C137FE3; Tue, 22 Aug 2006 10:23:54 +0200 (CEST) Original-Received: from smtp4-1-sn2.hy.skanova.net (smtp4-1-sn2.hy.skanova.net [81.228.8.92]) by av9-1-sn2.hy.skanova.net (Postfix) with ESMTP id 2BB5E37E6D; Tue, 22 Aug 2006 10:23:54 +0200 (CEST) Original-Received: from coolsville.localdomain (81-235-205-204-no59.tbcn.telia.com [81.235.205.204]) by smtp4-1-sn2.hy.skanova.net (Postfix) with ESMTP id 2896B37E46; Tue, 22 Aug 2006 10:23:52 +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:58701 Archived-At: YAMAMOTO Mitsuharu skrev: >>>>>> On Tue, 22 Aug 2006 08:38:54 +0200, Jan Dj=E4rv said: >=20 >> How can it be otherwise? If you only have one program counter, that >> program counter must be changed to the signal handler no matter how >> many threads you have, i.e. any previous execution (regardless of >> thread) is interrupted. >=20 > Not-running threads have already been *interrupted* by context > switching. Are they interrupted by a signal again? What exactly do you mean by interrupted? In the sense that they don't ge= t to=20 execute, yes they are interrupted. When a signal handler is running, no=20 threads can run (on a single CPU machine), hence they are all interrupted= . > I don't understand why non-signalled threads are relevant as long as a > signal handler only executes thread-safe functions. The problem of > async-signal-unsafe function is that a thread that took a lock in the > normal context may try to take the same lock in a signal handler > context. The thread cannot go back to the normal context where the > lock will be released afterwards, but just waits for the lock in the > signal handler. As a result, the thread gets stuck. That's > irrelevant to the other threads. That can't be it. The mutex is recursive, so a thread is able to take it= =20 multiple times. Jan D.