From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Clinton Ebadi Newsgroups: gmane.lisp.guile.devel,gmane.lisp.guile.user Subject: Re: Killing off scm_init_guile for Guile 2.0 ? Date: Fri, 23 Jan 2009 01:13:27 -0500 Message-ID: <87wscmk0s8.fsf@unknownlamer.org> References: <49dd78620901151530o66a2641ax47e526d15fc09faf@mail.gmail.com> <20090116213215.YITDV.179685.root@cdptpa-web09-z02> <3ae3aa420901161736u5de528d5gc75da062fb036115@mail.gmail.com> <49dd78620901221802i36618f94qcc4bf56a89d32a46@mail.gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1232691239 941 80.91.229.12 (23 Jan 2009 06:13:59 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 23 Jan 2009 06:13:59 +0000 (UTC) Cc: linasvepstas@gmail.com, Guile User , guile-devel To: Neil Jerram Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Fri Jan 23 07:15:11 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 1LQFJt-0000U9-LJ for guile-devel@m.gmane.org; Fri, 23 Jan 2009 07:15:09 +0100 Original-Received: from localhost ([127.0.0.1]:43916 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LQFIX-0007k3-GT for guile-devel@m.gmane.org; Fri, 23 Jan 2009 01:13:45 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LQFIS-0007hC-9G for guile-devel@gnu.org; Fri, 23 Jan 2009 01:13:40 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LQFIR-0007fL-9Q for guile-devel@gnu.org; Fri, 23 Jan 2009 01:13:39 -0500 Original-Received: from [199.232.76.173] (port=34166 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LQFIR-0007eu-08; Fri, 23 Jan 2009 01:13:39 -0500 Original-Received: from deleuze.hcoop.net ([69.90.123.67]:43669) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LQFIQ-0005yO-M8; Fri, 23 Jan 2009 01:13:38 -0500 Original-Received: from cpe-024-211-230-216.nc.res.rr.com ([24.211.230.216] helo=rvannith) by deleuze.hcoop.net with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1LQFIN-0003yQ-UG; Fri, 23 Jan 2009 01:13:36 -0500 In-Reply-To: <49dd78620901221802i36618f94qcc4bf56a89d32a46@mail.gmail.com> (Neil Jerram's message of "Fri, 23 Jan 2009 02:02:15 +0000") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 1) 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:8065 gmane.lisp.guile.user:7087 Archived-At: Neil Jerram writes: >> The problem is, >> of course, that if you scm_init_guile in some .so, >> you will accidentally place the entire system into guile >> mode, and not just the .so, as intended. > > Or, to put that another way, the "guile mode"-ness persists on the > thread that called your libguile-using code, even after the thread has > returned back into the depths of the application. That might not be a > problem, but it could be. For example, threads in guile mode are > (currently; I'm not sure what BDW-GC will do) paused when a garbage > collection is needed; so activity on another guile thread could > suddenly block the application thread; or more likely the other way > round: the GC would not be able to proceed, because the application > thread would not actually pause. Does Guile mode actually have any meaning when using the BDW GC? The BDW GC algorithm does not need to put other threads to sleep when sweeping; it does this implicitly by causing the functions that register collectable memory to block during the sweep phase as far as I can tell. The libc malloc/free can continue doing whatever they want in the meantime. A thread blocking for any reason should not be a problem as a result (does Guile mode have another other restrictions?). http://www.hpl.hp.com/personal/Hans_Boehm/gc/gcdescr.html has a good overview of the BDW GC algorithm, and a few links to related papers describing the algorithms used in more detail. -- It's no contest, but we still race there Like the saintly tortoise and the godless hare