From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.lisp.guile.user Subject: Re: Why launch the Guile signal delivery thread on exit? (was Re: guile 2.0.9 build on mingw) Date: Wed, 19 Jun 2013 18:51:35 +0300 Message-ID: <83vc5ap08o.fsf@gnu.org> References: <83sj1hv2ml.fsf@gnu.org> <874ndx9y7h.fsf@pobox.com> <83ip2bt4qk.fsf@gnu.org> <8761xqhyyt.fsf@gnu.org> <83li6mt18y.fsf@gnu.org> <83wqq3mcq9.fsf@gnu.org> <87k3m3kor5.fsf@gnu.org> <83ehcalysu.fsf@gnu.org> <87sj0pvl4a.fsf@tines.lan> <837gi1n3v5.fsf@gnu.org> <87k3m1vg8b.fsf@tines.lan> <83txl4lhby.fsf@gnu.org> <87txl4mh5p.fsf@gnu.org> <83a9mvkysg.fsf@gnu.org> <87li67cck5.fsf_-_@tines.lan> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE X-Trace: ger.gmane.org 1371657108 22928 80.91.229.3 (19 Jun 2013 15:51:48 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 19 Jun 2013 15:51:48 +0000 (UTC) Cc: guile-user@gnu.org, ludo@gnu.org To: Mark H Weaver Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Wed Jun 19 17:51:46 2013 Return-path: Envelope-to: guile-user@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1UpKfh-0002A2-Mq for guile-user@m.gmane.org; Wed, 19 Jun 2013 17:51:45 +0200 Original-Received: from localhost ([::1]:58168 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UpKfh-0000CP-CK for guile-user@m.gmane.org; Wed, 19 Jun 2013 11:51:45 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39559) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UpKfW-0000CG-NB for guile-user@gnu.org; Wed, 19 Jun 2013 11:51:36 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UpKfR-0008Nr-UB for guile-user@gnu.org; Wed, 19 Jun 2013 11:51:34 -0400 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:58787) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UpKfR-0008Nf-Lz; Wed, 19 Jun 2013 11:51:29 -0400 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0MON00D00DATIK00@a-mtaout22.012.net.il>; Wed, 19 Jun 2013 18:51:28 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MON00D7UDDRGV20@a-mtaout22.012.net.il>; Wed, 19 Jun 2013 18:51:28 +0300 (IDT) In-reply-to: <87li67cck5.fsf_-_@tines.lan> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.172 X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-user-bounces+guile-user=m.gmane.org@gnu.org Original-Sender: guile-user-bounces+guile-user=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.user:10474 Archived-At: > From: Mark H Weaver > Cc: Eli Zaretskii , ludo@gnu.org (Ludovic Court=E8s),= guile-user@gnu.org > Date: Tue, 18 Jun 2013 17:51:38 -0400 >=20 > The signal delivery thread is not launched until the first signal > handler is installed. This would seem sensible if not for the fact= that > it is always launched at exit, which I found surprising. Since launching a signal delivery thread hangs even if it happens early in the program run, like as result of (sigaction SIGINT) I looked closer at what happens when that thread starts. What I foun= d is this: - scm_spawn_thread calls scm_i_pthread_create - a new thread is created running the spawn_thread function, and GDB announces the new thread - spawn_thread calls scm_i_pthread_detach, which calls pthread_detach, which in turn calls pthread_mutex_lock, which hangs inside WaitForSingleObjectEx - scm_spawn_thread waits inside scm_i_scm_pthread_cond_wait for the thread to release the conditional variable, which never happens. So guile waits forever, a.k.a. "hangs". According to this part of pthread_detach: if (result =3D=3D 0) { =09 /* Thread is joinable */ =09 if (destroyIt) =09 { =09 /* The thread has exited or is exiting but has not been joine= d or =09 * detached. Need to wait in case it's still exiting. =09 */ =09 (void) WaitForSingleObject(tp->threadH, INFINITE); =09 ptw32_threadDestroy (thread); =09 } } it seems like pthreads thinks that the thread has exited or is exiting. But if the thread really exited, for whatever reasons, why doesn't WaitForSingleObject return? Does this ring a bell for someone?