From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Mark H Weaver Newsgroups: gmane.lisp.guile.devel Subject: Re: C calling Scheme and garbage collection Date: Sun, 30 Jun 2019 21:26:24 -0400 Message-ID: <8736jqk0jj.fsf@netris.org> 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="147371"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) Cc: guile-devel@gnu.org To: Isaac Jurado Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Mon Jul 01 03:27:24 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 1hhl6K-000cDk-6H for guile-devel@m.gmane.org; Mon, 01 Jul 2019 03:27:24 +0200 Original-Received: from localhost ([::1]:47136 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hhl6I-0007lp-IZ for guile-devel@m.gmane.org; Sun, 30 Jun 2019 21:27:22 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:58928) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hhl5l-0007lX-SY for guile-devel@gnu.org; Sun, 30 Jun 2019 21:26:50 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hhl5j-0001GU-Sp for guile-devel@gnu.org; Sun, 30 Jun 2019 21:26:49 -0400 Original-Received: from world.peace.net ([64.112.178.59]:42554) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hhl5i-00019u-1r for guile-devel@gnu.org; Sun, 30 Jun 2019 21:26:47 -0400 Original-Received: from mhw by world.peace.net with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1hhl5d-0002M6-Tm; Sun, 30 Jun 2019 21:26:42 -0400 In-Reply-To: (Isaac Jurado's message of "Thu, 27 Jun 2019 18:38:38 +0200") X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 64.112.178.59 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:19997 Archived-At: Hi Isaac, Isaac Jurado writes: > I'm playing with event loop libraries implemented in C (libev, > libevent, etc... in my case libsystemd), but configuring them from > Guile. > > The qsort example in the documentation [1] seems safe because the > qsort C function directly calls back, so the callback Scheme bindings > stay referenced (by the Scheme code calling qsort) during all the C > code execution. > > Now, in C event loops the situation is different. There is one call > to configure the event callback, in which the function and data > pointers are lent to the loop; and then there is the main loop or the > single iteration call. > > The way I see it, suppose I add a timer. I call one C function > passing a (proceudre->pointer) and an (scm->pointer). In a future > time, those pointers will be used by the C event loop. If a garbage > collection happens in the middle, the results of (procedure->pointer) > and (scm->pointer) may have been reclaimed by the time the C event > loop calls back. That's right. When passing pointers to GC-allocated blocks to arbitrary C code, you must take care to keep GC-visible references to those pointers until they are no longer needed. This will not happen automatically, unless the C code was specifically written to ensure that the references will be visible to the GC. BDW-GC does *not* scan arbitrary C data structures. In particular, blocks allocated using C 'malloc' or C++ 'new' are not scanned. > However, I've tried forcing (gc) between the two steps mentioned and > it looks to be working fine. As Greg mentioned, this isn't a sufficient test. In general, I would avoid relying on experiments to determine what is safe to do. Experiments can only tell you how the tested version(s) behave. They cannot give you assurances about how future versions are supposed to behave. > I have also reviewed some of the code [2][3] and some additional weak > references seem to be created. Those weak references do not eliminate the need to keep GC-visible references to the relevant objects. They merely ensure that *if* you keep a reference to the returned pointer, the other associated data structures are also kept alive. Regards, Mark