From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Greg Troxel Newsgroups: gmane.lisp.guile.devel Subject: Re: C calling Scheme and garbage collection Date: Sat, 29 Jun 2019 13:44:01 -0400 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="28632"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (berkeley-unix) Cc: guile-devel@gnu.org To: Isaac Jurado Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sat Jun 29 19:44:20 2019 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1hhHOd-0007HR-77 for guile-devel@m.gmane.org; Sat, 29 Jun 2019 19:44:19 +0200 Original-Received: from localhost ([::1]:41660 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hhHOb-0002s8-Ky for guile-devel@m.gmane.org; Sat, 29 Jun 2019 13:44:17 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:36366) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hhHOU-0002rp-8q for guile-devel@gnu.org; Sat, 29 Jun 2019 13:44:11 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hhHOT-0003GP-8C for guile-devel@gnu.org; Sat, 29 Jun 2019 13:44:10 -0400 Original-Received: from s1.lexort.com ([71.19.148.97]:60851) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hhHOR-0003F8-Dg for guile-devel@gnu.org; Sat, 29 Jun 2019 13:44:08 -0400 Original-Received: by s1.lexort.com (Postfix, from userid 10853) id 51DFF410C29; Sat, 29 Jun 2019 13:44:01 -0400 (EDT) OpenPGP: id=098ED60E In-Reply-To: (Isaac Jurado's message of "Fri, 28 Jun 2019 13:07:53 +0200") X-detected-operating-system: by eggs.gnu.org: FreeBSD 8.x [fuzzy] X-Received-From: 71.19.148.97 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Original-Sender: "guile-devel" Xref: news.gmane.org gmane.lisp.guile.devel:19991 Archived-At: Isaac Jurado writes: > On Thu, Jun 27, 2019 at 9:52 PM Greg Troxel wrote: > >> I have been down this path before, with guile and with lua. Basically, >> if C (or non-scheme) has a pointer to a scheme object, then you need to >> hold a logical reference for it and protect the scheme object, and when >> the C pointer is dropped decrease the refcnt. >> >> I am unclear on the details of how you have a ref that gc is made aware >> of. One way is to have a scheme array of the object and a count, and >> have the code null out the object when the count goes to zero or >> something like that. But the point is that you need to have a proxy in >> the scheme world, visible to gc, when a pointer to a scheme object is >> held outside of the scheme world. >> > > That's more or less what I had in mind, although instead of an array I > would use a hash table indexed by a fundamental type (e.g. integer) which > can be converted painlessly between Scheme and C. Sure - it just needs to be something the gc will find. > I prepared a minimal case of the kind of C interactions that I'm trying. > I'm attaching the files, the C code has to be compiled with: > > gcc -shared -fPIC -o mysalsa.so mysalsa.c > > Running the Scheme script yields something like the following: > > Captured: Closure without collection > Argument: noitcelloc tuohtiw erusolC > Captured: Closure with garbate collected > Argument: > > So primitive values seem to be garbage collected, but closures are treated > slightly differently. This is very interesting, since working with > closures eliminates the need of those common "void *userdata" extra > arguments. > > Testing continuation is going to be interesting too. Just because something wasn't collected doesn't mean it is safe. You don't actually know that the closure wasn't garbage collected, just that when you used it the bits were still there. You might try running under valgrind. Or modify guile to clear all objects that are garbage collected, which I'm guessing it doesn't do. In my experience, it's definitely not ok to capture a pointer to a scheme object and store it for later use without protecting the scheme object from gc by holding a reference.