From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: ludo@gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=) Newsgroups: gmane.lisp.guile.devel Subject: Re: Bug #27457 =?utf-8?b?KOKAnFRocmVhZHMs?= mutexes, and critical =?utf-8?b?c2VjdGlvbnPigJ0p?= Date: Thu, 01 Oct 2009 19:21:08 +0200 Message-ID: <87ocorni7v.fsf@gnu.org> References: <0489FB6F-567B-4967-9703-1A3D89462A37@raeburn.org> <79F7A852-10ED-46DF-9D41-ED545493E8FE@raeburn.org> <87pr9dpgfw.fsf@gnu.org> <871vlr6l2p.fsf@ossau.uklinux.net> <87k4zi6h3q.fsf@gnu.org> <87eipqn12l.fsf@ossau.uklinux.net> <87eipqzmdr.fsf_-_@gnu.org> <87tyykw3lm.fsf@ossau.uklinux.net> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1254419559 26255 80.91.229.12 (1 Oct 2009 17:52:39 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 1 Oct 2009 17:52:39 +0000 (UTC) Cc: Ken Raeburn , guile-devel@gnu.org To: Neil Jerram Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Thu Oct 01 19:52:32 2009 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1MtPpN-0001Y6-Ij for guile-devel@m.gmane.org; Thu, 01 Oct 2009 19:52:30 +0200 Original-Received: from localhost ([127.0.0.1]:40213 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MtPpN-0005jr-0i for guile-devel@m.gmane.org; Thu, 01 Oct 2009 13:52:29 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MtPLD-0001a3-Dd for guile-devel@gnu.org; Thu, 01 Oct 2009 13:21:19 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MtPL8-0001UW-SL for guile-devel@gnu.org; Thu, 01 Oct 2009 13:21:18 -0400 Original-Received: from [199.232.76.173] (port=40237 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MtPL8-0001UM-Mz for guile-devel@gnu.org; Thu, 01 Oct 2009 13:21:14 -0400 Original-Received: from mail4-relais-sop.national.inria.fr ([192.134.164.105]:41164) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.60) (envelope-from ) id 1MtPL8-0000Bv-0Q for guile-devel@gnu.org; Thu, 01 Oct 2009 13:21:14 -0400 X-IronPort-AV: E=Sophos;i="4.44,488,1249250400"; d="scan'208";a="47709455" Original-Received: from reverse-83.fdn.fr (HELO nixey) ([80.67.176.83]) by mail4-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES128-SHA; 01 Oct 2009 19:21:11 +0200 X-URL: http://www.fdn.fr/~lcourtes/ X-Revolutionary-Date: 10 =?iso-8859-1?Q?Vend=E9miaire?= an 218 de la =?iso-8859-1?Q?R=E9volution?= X-PGP-Key-ID: 0xEA52ECF4 X-PGP-Key: http://www.fdn.fr/~lcourtes/ludovic.asc X-PGP-Fingerprint: 821D 815D 902A 7EAB 5CEE D120 7FBA 3D4F EB1F 5364 X-OS: x86_64-unknown-linux-gnu In-Reply-To: <87tyykw3lm.fsf@ossau.uklinux.net> (Neil Jerram's message of "Wed, 30 Sep 2009 21:59:49 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:9425 Archived-At: Hi Neil, Neil Jerram writes: > ludo@gnu.org (Ludovic Court=C3=A8s) writes: > >> I should have mentioned this one: >> http://thread.gmane.org/gmane.comp.programming.garbage-collection.boehmg= c/3185 . >> >> This is normally somewhat fixed in current BDW-GC CVS, but Guile itself >> may have troubles of its own dealing with cancellation. > > Thanks. I thought already about cancellation, but I couldn't see > anything in the test program that would do that. Do you know of > anything in that program, or in BDW-GC, that does a pthread_cancel? Hmm no, sorry for the confusion. The srfi-18 test this was taken from did use cancellation, though. > I've cherry-picked the following branch_release-1-8 fixes. > > commit 499c43b03225abb8d3af9087b7630d523b74e13a > Author: Neil Jerram > Date: Thu Mar 5 20:03:33 2009 +0000 > > Avoid throw from critical section, given invalid sigaction call > > (This is for a different critical section problem, but which still > occurs (prior to this commit) in master.) Good that you noticed it was missing from =E2=80=98master=E2=80=99. (BTW = =E2=80=98signals.test=E2=80=99 should be changed to GPLv3+ and have a =E2=80=98define-module=E2=80=99 clau= se.) > commit 3009b5d557e1ebfd828fd0de9b1da5abb2f6ec9a > Author: Neil Jerram > Date: Tue Mar 10 23:55:31 2009 +0000 > > Fix spurious `throw from within critical section' errors > > (This is the commit that I hope will fix the errors that you're seeing.) > > Can you see how the test runs now? The abort=C2=A0() is apparently never reached with this patch. It took me some time to understand this: - if (scm_i_critical_section_level) + if (thread->critical_section_level) { fprintf (stderr, "continuation invoked from within critical section.= \n"); abort (); Critical sections concern all the threads in guile mode. Thus I would think that the question =E2=80=9Care the threads in a critical section?=E2= =80=9D cannot be answered by looking at a per-thread =E2=80=98critical_section_level=E2= =80=99. However, it really seems that the intent was really to forbid =E2=80=98thro= w=E2=80=99s when the *current thread* is holding the critical section mutex, so the patch is correct but I find the name =E2=80=98critical_section_level=E2=80= =99 is slightly misleading. What do you think? > Also, can I check my thinking on one other fix, and how it > interacts with BDW-GC? > > commit 2bfcaf2605f8366d8c708c148bde5313b88497e0 > Author: Neil Jerram > Date: Wed Mar 4 23:45:11 2009 +0000 > > Lock ordering: don't allocate when in critical section (scm_sigaction= _for_thread) > > With BDW-GC I believe that allocation in a critical section is no longer > a problem, specifically because > > - the stop-the-world mechanism uses signals and sigsuspend - whereas > Guile GC used mutexes - and hence there are no concerns about lock > ordering > > - it doesn't matter if there are threads waiting for the critical > section when a GC happens, because the signal mechanism will still > interrupt them. > > Is that right? Yes. BTW, rest assured: thanks to libgc we won=E2=80=99t get any Helgrind report! :-) Thanks, Ludo=E2=80=99.