From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Brett Viren Newsgroups: gmane.lisp.guile.user Subject: Re: C++ application linked with guile dos not quite Date: Tue, 18 Jun 2002 10:45:29 -0400 Sender: guile-user-admin@gnu.org Message-ID: <15631.18313.578397.245899@minos.phy.bnl.gov> References: <1024320297.17552.141.camel@tice> <1024388708.23129.28.camel@tice> <15631.14600.194325.589914@minos.phy.bnl.gov> <1024411071.6804.3.camel@tice> Reply-To: Brett Viren NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: main.gmane.org 1024411773 3375 127.0.0.1 (18 Jun 2002 14:49:33 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Tue, 18 Jun 2002 14:49:33 +0000 (UTC) Cc: Guile user Return-path: Original-Received: from fencepost.gnu.org ([199.232.76.164]) by main.gmane.org with esmtp (Exim 3.33 #1 (Debian)) id 17KKIW-0000sJ-00 for ; Tue, 18 Jun 2002 16:49:32 +0200 Original-Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 17KKH9-0001r8-00; Tue, 18 Jun 2002 10:48:07 -0400 Original-Received: from smtpgw.bnl.gov ([130.199.3.16]) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 17KKEh-0001jM-00 for ; Tue, 18 Jun 2002 10:45:35 -0400 Original-Received: from bnl.gov ([130.199.128.163]) by smtpgw.bnl.gov with esmtp (Exim 3.35 #1 ) id 17KKEe-0000t6-00; Tue, 18 Jun 2002 10:45:32 -0400 Original-Received: from minos (minos.phy.bnl.gov [130.199.36.108]) by bnl.gov (8.9.2/1.0.0-BNL) with ESMTP id KAA23739; Tue, 18 Jun 2002 10:45:31 -0400 (EDT) Original-Received: from bviren by minos with local (Exim 3.34 #1 (Debian)) id 17KKEb-0002rq-00; Tue, 18 Jun 2002 10:45:29 -0400 Original-To: Hilaire Fernandes In-Reply-To: <1024411071.6804.3.camel@tice> X-Mailer: VM 7.03 under 21.4 (patch 6) "Common Lisp" XEmacs Lucid Errors-To: guile-user-admin@gnu.org X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.0.9 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.lisp.guile.user:608 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.user:608 Hilaire Fernandes writes: > I do not use any scm_ methods actualy, I do not know anything about > them. I do not know if guile use it internaly then wait for it to be > unprotected. I don't think there is ever a time that you must call scm_unprotect_object() unless you explicitly called scm_protect_object(). > Well I am wondering what is for scm_protect_object(). You would only need scm_protect_object() on any SCM if two cases are met: 1) you store the SCM in your C/C++ code for multiple calls to gh_ or scm_ functions (ie, any time that a garbage collection might happen). 2) If there is any chance that all internal references to the SCM will disappear. Since garbage collection looks at reference counts, if your C/C++ code is still referring to an SCM, but nothing on the guile side is, then the ref count can go to zero and the GC thinks it's okay to reap the SCM (since it doesn't know about your C/C++ reference). The protect/unprotect just increments/decrements the ref count. > Is there some special procedure to free memory from a SCM object? > For example the value returned by a call to guile procedure? Not that I know of. I have always done things via scm_(un)protect_object(). BTW, you can force a garbage collection via scm_gc(). Durring debugging I would call this once per "cycle" of my program. This greatly slowed things down, but it will trigger a SegV immediately so it is easier to know when something is going wrong. Again, I am no expert, but since the experts seem to be quiet today, I hope this helps. -Brett. _______________________________________________ Guile-user mailing list Guile-user@gnu.org http://mail.gnu.org/mailman/listinfo/guile-user