unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
From: Greg Troxel <gdt@lexort.com>
To: Isaac Jurado <diptongo@gmail.com>
Cc: guile-devel@gnu.org
Subject: Re: C calling Scheme and garbage collection
Date: Sat, 29 Jun 2019 13:44:01 -0400	[thread overview]
Message-ID: <rmiblygmgm6.fsf@s1.lexort.com> (raw)
In-Reply-To: <CALqPu34W=e-JQ_dHBf21XhOeeqX+w0C-Jgx80JKb+83XcExUjA@mail.gmail.com> (Isaac Jurado's message of "Fri, 28 Jun 2019 13:07:53 +0200")

Isaac Jurado <diptongo@gmail.com> writes:

> On Thu, Jun 27, 2019 at 9:52 PM Greg Troxel <gdt@lexort.com> 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.



  reply	other threads:[~2019-06-29 17:44 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-27 16:38 C calling Scheme and garbage collection Isaac Jurado
2019-06-27 19:52 ` Greg Troxel
2019-06-28 11:07   ` Isaac Jurado
2019-06-29 17:44     ` Greg Troxel [this message]
2019-06-30 12:17       ` David Pirotte
2019-06-30 20:05       ` Isaac Jurado
2019-06-30 12:51   ` Hans Åberg
2019-07-01  1:26 ` Mark H Weaver

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/guile/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=rmiblygmgm6.fsf@s1.lexort.com \
    --to=gdt@lexort.com \
    --cc=diptongo@gmail.com \
    --cc=guile-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).