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: guile 2.0.9 build on mingw Date: Mon, 10 Jun 2013 19:23:45 +0300 Message-ID: <83ehcalysu.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> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE X-Trace: ger.gmane.org 1370881439 10080 80.91.229.3 (10 Jun 2013 16:23:59 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 10 Jun 2013 16:23:59 +0000 (UTC) Cc: guile-user@gnu.org To: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Mon Jun 10 18:23:59 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 1Um4sw-00083G-0b for guile-user@m.gmane.org; Mon, 10 Jun 2013 18:23:58 +0200 Original-Received: from localhost ([::1]:53212 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Um4sv-0001R3-Fm for guile-user@m.gmane.org; Mon, 10 Jun 2013 12:23:57 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37252) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Um4sk-0001QQ-6E for guile-user@gnu.org; Mon, 10 Jun 2013 12:23:50 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Um4si-0006ZC-Ku for guile-user@gnu.org; Mon, 10 Jun 2013 12:23:46 -0400 Original-Received: from mtaout21.012.net.il ([80.179.55.169]:57029) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Um4si-0006Yx-Bz; Mon, 10 Jun 2013 12:23:44 -0400 Original-Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0MO600D00QRYMH00@a-mtaout21.012.net.il>; Mon, 10 Jun 2013 19:23:43 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MO600DJ3QVJHX50@a-mtaout21.012.net.il>; Mon, 10 Jun 2013 19:23:43 +0300 (IDT) In-reply-to: <87k3m3kor5.fsf@gnu.org> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.169 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:10422 Archived-At: > From: ludo@gnu.org (Ludovic Court=C3=A8s) > Cc: guile-user@gnu.org > Date: Sun, 09 Jun 2013 22:33:50 +0200 >=20 > Eli Zaretskii skribis: >=20 > > There's only one thread at this point, its backtrace is below. > > Actually, I don't see more than this one thread during the entire= run > > (GDB doesn't announce any thread birth or death, and Process Expl= orer > > shows a single thread in the process at all times). Note that we= are > > talking about a child guile process -- it's that one that prints = the > > weird traceback and hangs. The parent just waits for the child t= o > > finish. >=20 > Where=E2=80=99s the child process created exactly? It=E2=80=99s no= t clear to me. Sorry, this was a red herring. The parent process is the guile.exe =66rom libguile, which is just a wrapper around the real guile.exe, which is hidden in its .libs subdirectory. So the parent is not important; only the child is. > Anyway, it could be that the parent Guile process has more than one > thread, and the child Guile process (which has only one thread) end= s up > with some mutexes locked, and possibly inconsistent state. See above: the parent is not really Guile, it's just called guile.exe to dupe all kinds of scripts (and me ;-). > Normally a Guile with multiple threads warns upon =E2=80=98fork= =E2=80=99, precisely > because of this problem (see =E2=80=98scm_fork=E2=80=99 in posix.c.= ) As I wrote earlier, there's no 'fork' in MinGW, so I'm not sure this is at all relevant. Or maybe it is -- perhaps the threads infrastructure in Guile really assumes Posix functionality that just isn't there in the MinGW build? > However, that warning doesn=E2=80=99t take into account the signal = thread, nor > the GC thread (if any). So, although that seems unlikely, there co= uld > still be issues, for instance if the =E2=80=98scm_fork=E2=80=99 cal= l happens while > =E2=80=98signal_delivery_thread_mutex=E2=80=99 is locked. What signal would that be? Are you sure it exists, or is emulated, o= n Windows? Thanks.