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: Sun, 30 Jun 2019 22:05:42 +0200 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000f67f54058c900999" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="240508"; 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 Sun Jun 30 22:06:49 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 1hhg65-0010T4-OU for guile-devel@m.gmane.org; Sun, 30 Jun 2019 22:06:49 +0200 Original-Received: from localhost ([::1]:46318 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hhg64-0001a8-83 for guile-devel@m.gmane.org; Sun, 30 Jun 2019 16:06:48 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:57134) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hhg5L-0001a1-35 for guile-devel@gnu.org; Sun, 30 Jun 2019 16:06:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hhg5J-0002ft-Lc for guile-devel@gnu.org; Sun, 30 Jun 2019 16:06:02 -0400 Original-Received: from mail-lf1-x12e.google.com ([2a00:1450:4864:20::12e]:45644) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hhg5H-0002Zq-31 for guile-devel@gnu.org; Sun, 30 Jun 2019 16:06:00 -0400 Original-Received: by mail-lf1-x12e.google.com with SMTP id u10so7249591lfm.12 for ; Sun, 30 Jun 2019 13:05:55 -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=qfdeSIZnBriawH0x4UqjUmMXsnl44uGrU/YpVos5xwM=; b=R/uaKyQYov2b5GrBwzQ73RXfqmMMwyIsYN/4HUIi3s/a6BS9nX7aqNQlOm/Vtr/Zok Y6x6uhGO3gXSzieizfhcR+YnU2LqkoU2XD1iWFBYAzeRECVuHSjLKXH21kyBk0P8ghZU t4sD4weaMyByes5VOusbz0bET+lWPeGbMoO4HcwiJ1/UX4aKa/ep84R0lRwQ3du4bbpV jIXak3oMaDnUh9HZHveub9AgpW/A7Fhs6ihRYfWTNx/PS65HfomyIY3d38aQtvF86BQT TwUqUXGxlYShjAMS03taK7LfnAbwJ6+lNZYDHcH69c7GKYFce9D31Mwgm2JfPg5tuhWj K/uQ== 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=qfdeSIZnBriawH0x4UqjUmMXsnl44uGrU/YpVos5xwM=; b=VTpPQsK0WPbG/6W/3ds+joCqmOcb0AB3PHxcZlYoN0ZX0W3ht/S4Z0IHIcU6dLOpp7 LlVETtqMKL9naRKlHpiBbEaYPgt8qCl396KGTnLNAqHy9PJPXRnI1LVdyizpJTkjS6O1 kISKrxo6zsbclHXP0Aqh6OLCKl8QexicKGWrV2VQDkW3euuoPqwjT/pkoUpqyZWxIbyh Ky71yC/3YXUO/VBtoWnA8fcJZEXLgbuF3MgSuCj09LSM6I6gR1+TOdvv2Db9+Wt+wKh1 XEyWzEdwcbjBQNqreNKcWajfo1ULpHR39IMO360qxIf6TPFZawFTjKqRLqAP8mUS6HHG qimA== X-Gm-Message-State: APjAAAWltUxMxrx5CYYeAB2gG7SQou/4qvLzDl+ZA15pH/6jcBOcz+l4 phPid85Q0rtnpTSWmwD49JrtJI4wuIF7NonDAzPrilZY X-Google-Smtp-Source: APXvYqx0pUPc4rngewIV5YWbr9bbdFo4CuFpIQ95uhVmzpxsbYDKU8OMMA3hng7ikiAtvFmGOQnWQMNcm2VxAH3L1Wk= X-Received: by 2002:ac2:5a44:: with SMTP id r4mr3576027lfn.118.1561925153880; Sun, 30 Jun 2019 13:05:53 -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::12e 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:19994 Archived-At: --000000000000f67f54058c900999 Content-Type: text/plain; charset="UTF-8" On Sat, Jun 29, 2019 at 7:44 PM Greg Troxel wrote: > 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. > My intention was quite the opposite, use something that the GC will NOT find, like 32/64 bit integers. I assumed that (pointer->procedure) and its inverse would convert from/to uint32, uint64, etc. natively, without creating GC objects. This way I can safely give a way such a value to the C code, while using it as a key to a Scheme hashmap. > 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. > Agreed, just like the old use after free(). > 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. > It's the sort of advice I was seeking to confirm, so thanks :-) Best regards. -- Isaac Jurado "The noblest pleasure is the joy of understanding" Leonardo da Vinci --000000000000f67f54058c900999 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sat, Jun 29, 2019 at 7:44 PM Greg Troxel <gdt@lexort.com> wrote:
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.=C2=A0 = Basically,
>> if C (or non-scheme) has a pointer to a scheme object, then you ne= ed 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 co= unt, and
>> 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 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 arr= ay I
> would use a hash table indexed by a fundamental type (e.g. integer) wh= ich
> can be converted painlessly between Scheme and C.

Sure - it just needs to be something the gc will find.

My intention was quite the opposite, use something that the= GC will NOT find, like 32/64 bit integers.=C2=A0 I assumed that (pointer-&= gt;procedure) and its inverse would convert from/to uint32, uint64, etc. na= tively, without creating GC objects.=C2=A0 This way I can safely give a way= such a value to the C code, while using it as a key to a Scheme hashmap.
=C2=A0
Just because something wasn't collected doesn't mean it is safe.=C2= =A0 You
don't actually know that the closure wasn't garbage collected, just= that
when you used it the bits were still there.=C2=A0 You might try running und= er
valgrind.=C2=A0 Or modify guile to clear all objects that are garbage
collected, which I'm guessing it doesn't do.
<= br>
Agreed, just like the old use after free().
=C2= =A0
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.

It's the sort of advice I was se= eking to confirm, so thanks :-)

Best regards.

--
Isaac Jur= ado

"The noblest pleasure is the joy of understanding"
= Leonardo da Vinci
--000000000000f67f54058c900999--