From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Isaac Jurado Newsgroups: gmane.lisp.guile.devel Subject: Re: C calling Scheme and garbage collection Date: Fri, 28 Jun 2019 13:07:53 +0200 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="000000000000e69feb058c604aed" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="223315"; mail-complaints-to="usenet@blaine.gmane.org" Cc: guile-devel@gnu.org To: Greg Troxel Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Fri Jun 28 15:14:17 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 1hgqhl-000w05-DF for guile-devel@m.gmane.org; Fri, 28 Jun 2019 15:14:17 +0200 Original-Received: from localhost ([::1]:59696 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hgqhk-0006ZX-BI for guile-devel@m.gmane.org; Fri, 28 Jun 2019 09:14:16 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:44216) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hgqM3-0003Zi-W5 for guile-devel@gnu.org; Fri, 28 Jun 2019 08:51:59 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hgqM0-00058Y-Hp for guile-devel@gnu.org; Fri, 28 Jun 2019 08:51:51 -0400 Original-Received: from mail-lj1-x231.google.com ([2a00:1450:4864:20::231]:34631) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hgqLx-00052t-CP for guile-devel@gnu.org; Fri, 28 Jun 2019 08:51:46 -0400 Original-Received: by mail-lj1-x231.google.com with SMTP id p17so5892134ljg.1 for ; Fri, 28 Jun 2019 05:51:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=qrSXMbjd6Q+bwmZXE5OxeAFl9BwWrFJGFhvDu69SaVo=; b=VgDY+3f/2HpBr0RLXYN5oTCtgXAOHWEf7NBHMh860dblIYSD29skvoTVjmA75OPp+l gdpWuqVWjyl4S1EKQuDEDM2OaQv1Mef3cw/zIIe+XukDVFxa7wJbCYnlc80aJ9wNmo/l 1FBmjLJfNT2928SDn4lbAPm9SLJA5prh5zogJsN+lKYG/2WzNJOLPojumvpGnplqU1Oc x9GnxvY7JuTIEuglMt6zRXqq+FRagAWKaRql2ZK47kMdcBg5IzlYj4keEi/8PiUsLnWf B53XeyrPTRAJMnSGmAtG7q8JbgD0u1TWuXPZ3OBijFQ6YA/jnia81Bl6yzENXafD6G03 Mf2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=qrSXMbjd6Q+bwmZXE5OxeAFl9BwWrFJGFhvDu69SaVo=; b=qylS2/QTUS8r6qyALAuC9OjPilflfPF9DIfneRjSxR6/85arZ735A/GxY7TGpHff9M 7K9r4oOvjXia/cq6zxLwvBhlp5DzcKczS80RT+6iQBJbHVj2x5OOZdxGjHoZ5jrDRCfy DopjidfwekTN613/YnpJtRQoQ7xLcJfpW21xbxUW0qeuft7oj/HUSaUx+5VGB6bn1aCa wbCjbGZP2WQUd8H6Yk6j0g9iZkpoyvnYsKd5gQrIzU7IZmUOjdE1QuYW0bU5xUjJ4kO6 mvYIn3IHk+8pIaczPLLRwIBW5mZ/2D9QguCj6W8qyW6F9L1nXr9+5TDimeroJUyh2X5A L3bg== X-Gm-Message-State: APjAAAUEcq4w9WoFlcHMxGVDS8uPEXnXcZPCoR2OLL+FhuryhghjDVAl UkrTVTc0SUZ+HHC/9dlPvB5MLdMWCx5wnaFeA2XRH6M4s+eZiA== X-Google-Smtp-Source: APXvYqxZn6m9RFkGDMduyAwwghlPYNRFybpLNTH3SZ1ef9PGwJujIZUL9hkaA4UxbFFAmR5a4xxUxBIaifl1pYjhzkw= X-Received: by 2002:a2e:b0d0:: with SMTP id g16mr5746960ljl.161.1561720084916; Fri, 28 Jun 2019 04:08:04 -0700 (PDT) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:4864:20::231 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:19990 Archived-At: --000000000000e69feb058c604aed Content-Type: multipart/alternative; boundary="000000000000e69fe9058c604aeb" --000000000000e69fe9058c604aeb Content-Type: text/plain; charset="UTF-8" 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. > Forcing gc is not going to be reliable. If you have a reliable scheme, > gc can happen at any random time and things will be ok. > 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. Best regards. -- Isaac Jurado "The noblest pleasure is the joy of understanding" Leonardo da Vinci --000000000000e69fe9058c604aeb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Thu, Jun 27, 2019 at 9:52 PM Greg Trox= el <gdt@lexort.com> wrote:
<= /div>

I have been down this path before, with guile and with lua.=C2=A0 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.=C2=A0 One way is to have a scheme array of the object and a count, and<= br> have the code null out the object when the count goes to zero or
something like that.=C2=A0 But the point is that you need to have=C2=A0 a p= roxy in
the scheme world, visible to gc, when a pointer to a scheme object is
held outside of the scheme world.

That&= #39;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.
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex"> Forcing gc is not going to be reliable.=C2=A0 =C2=A0If you have a reliable = scheme,
gc can happen at any random time and things will be ok.

I prepared a minimal case of the kin= d of C interactions that I'm trying.=C2=A0 I'm attaching the files,= the C code has to be compiled with:

gcc -shared -= fPIC -o mysalsa.so mysalsa.c

Running the Scheme sc= ript yields something like the following:

Captured= : Closure without collection
Argument: noitcelloc tuohtiw erusolC
Cap= tured: Closure with garbate collected
Argument:=C2=A0

So primitive values seem to be garbage collected, but closures are t= reated slightly differently.=C2=A0 This is very interesting, since working = with closures eliminates the need of those common "void *userdata"= ; extra arguments.

Testing continuation is going t= o be interesting too.

Best regards.
=
--
Isaac Jurado
"The noblest pleasure is the joy of understanding"
Leonar= do da Vinci
--000000000000e69fe9058c604aeb-- --000000000000e69feb058c604aed Content-Type: text/x-csrc; charset="US-ASCII"; name="mysalsa.c" Content-Disposition: attachment; filename="mysalsa.c" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_jxfzsya40 dHlwZWRlZiB2b2lkICgqY2FsbGJhY2tfdCkgKHZvaWQgKik7CgpzdGF0aWMgY2FsbGJhY2tfdCBz YXZlZF9jYWxsYmFjazsKc3RhdGljIHZvaWQgKnNhdmVkX2FyZzsKCnZvaWQgZ2l2ZSAoY2FsbGJh Y2tfdCBjYWxsYmFjaywgdm9pZCAqYXJnKQp7CiAgICAgICAgc2F2ZWRfY2FsbGJhY2sgPSBjYWxs YmFjazsKICAgICAgICBzYXZlZF9hcmcgPSBhcmc7Cn0KCnZvaWQgY2FsbCAoKQp7CiAgICAgICAg c2F2ZWRfY2FsbGJhY2soc2F2ZWRfYXJnKTsKfQo= --000000000000e69feb058c604aed Content-Type: text/x-scheme; charset="US-ASCII"; name="mysalsa.scm" Content-Disposition: attachment; filename="mysalsa.scm" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_jxfzsyag1 KHVzZS1tb2R1bGVzIChzeXN0ZW0gZm9yZWlnbikpCgooZGVmaW5lIGxpYiAoZHluYW1pYy1saW5r IChzdHJpbmctYXBwZW5kIChnZXRjd2QpICIvbXlzYWxzYSIpKSkKKGRlZmluZSBnaXZlIChwb2lu dGVyLT5wcm9jZWR1cmUgdm9pZCAoZHluYW1pYy1mdW5jICJnaXZlIiBsaWIpICcoKiAqKSkpCihk ZWZpbmUgY2FsbCAocG9pbnRlci0+cHJvY2VkdXJlIHZvaWQgKGR5bmFtaWMtZnVuYyAiY2FsbCIg bGliKSAnKCkpKQoKKGRlZmluZSAoc2ltcGxlLWNsb3N1cmUgY2FwdHVyZSkKICAobGV0IChbcHJv YyAobGFtYmRhIChhcmcpCiAgICAgICAgICAgICAgICAoZGlzcGxheSAoc3RyaW5nLWFwcGVuZCAi Q2FwdHVyZWQ6ICIgY2FwdHVyZSkpCiAgICAgICAgICAgICAgICAobmV3bGluZSkKICAgICAgICAg ICAgICAgIChkaXNwbGF5IChzdHJpbmctYXBwZW5kICJBcmd1bWVudDogIiAocG9pbnRlci0+c3Ry aW5nIGFyZykpKQogICAgICAgICAgICAgICAgKG5ld2xpbmUpKV0KICAgICAgICBbYXJnIChzdHJp bmctcmV2ZXJzZSBjYXB0dXJlKV0pCiAgICAoZ2l2ZSAocHJvY2VkdXJlLT5wb2ludGVyIHZvaWQg cHJvYyAnKCopKSAoc3RyaW5nLT5wb2ludGVyIGFyZykpKSkKCgooc2ltcGxlLWNsb3N1cmUgIkNs b3N1cmUgd2l0aG91dCBjb2xsZWN0aW9uIikKKGNhbGwpCihnYykKCihzaW1wbGUtY2xvc3VyZSAi Q2xvc3VyZSB3aXRoIGdhcmJhdGUgY29sbGVjdGVkIikKKGdjKQooY2FsbCkKCgogICAgICAgICAg ICAgCiAgCgoKCgogIAo= --000000000000e69feb058c604aed--