From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: NIIBE Yutaka Newsgroups: gmane.lisp.guile.devel,gmane.lisp.guile.user Subject: Re: Threads and asyncs Date: Wed, 4 Sep 2002 09:28:45 +0900 (JST) Sender: guile-devel-admin@gnu.org Message-ID: <200209040028.g840Sjv08056@mule.m17n.org> References: <87it1oglmq.fsf@zagadka.ping.de> <87d6rvaqyc.fsf@zagadka.ping.de> NNTP-Posting-Host: localhost.gmane.org X-Trace: main.gmane.org 1031099263 7154 127.0.0.1 (4 Sep 2002 00:27:43 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Wed, 4 Sep 2002 00:27:43 +0000 (UTC) Cc: guile-devel@gnu.org, guile-user@gnu.org Return-path: Original-Received: from monty-python.gnu.org ([199.232.76.173]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 17mO1F-0001rG-00 for ; Wed, 04 Sep 2002 02:27:42 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10) id 17mO2l-0000tB-00; Tue, 03 Sep 2002 20:29:15 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 17mO2T-0000o9-00 for guile-devel@gnu.org; Tue, 03 Sep 2002 20:28:57 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 17mO2Q-0000m6-00 for guile-devel@gnu.org; Tue, 03 Sep 2002 20:28:56 -0400 Original-Received: from tsukuba.m17n.org ([192.47.44.130]) by monty-python.gnu.org with esmtp (Exim 4.10) id 17mO2Q-0000m2-00; Tue, 03 Sep 2002 20:28:54 -0400 Original-Received: from fs.m17n.org (fs.m17n.org [192.47.44.2]) by tsukuba.m17n.org (8.11.6/3.7W-20010518204228) with ESMTP id g840SkK15325; Wed, 4 Sep 2002 09:28:46 +0900 (JST) (envelope-from gniibe@m17n.org) Original-Received: from mule.m17n.org (mule [192.47.44.3]) by fs.m17n.org (8.11.3/3.7W-20010823150639) with ESMTP id g840Sjd04921; Wed, 4 Sep 2002 09:28:46 +0900 (JST) Original-Received: (from gniibe@localhost) by mule.m17n.org (8.11.3/3.7W-19990512194415) id g840Sjv08056; Wed, 4 Sep 2002 09:28:45 +0900 (JST) X-Authentication-Warning: mule.m17n.org: gniibe set sender to gniibe@m17n.org using -f Original-To: Marius Vollmer In-Reply-To: <87d6rvaqyc.fsf@zagadka.ping.de> Errors-To: guile-devel-admin@gnu.org X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Developers list for Guile, the GNU extensibility library List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.lisp.guile.devel:1267 gmane.lisp.guile.user:928 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:1267 In threaded applications, we should avoid "asynchronous" signal handling. This is some sort of common technique/discipline, I think. If we do want asynchronous signal handling in threaded applications, we'll open can of dead-lock worms. Signal handler will access some shared data to affect some thread control, which means, need some mutual exclusion for that. What if when signal hander will be invoked asynchronously in the critical region? Signal handler cannot get the lock. That'll be cause of the dead lock(s). (Usually) In threaded applications, signal is handled synchronously, by assigning a dedicated thread for signal handling. I mean, a thread like that: while (1) { switch (get_signal ()) /* Blocked if none */ { case SIGINT: sigint_handler (); break; case SIGHUP: sighup_handler (); break; /* ... */ } } -- _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel