From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Dimitris Papavasiliou Newsgroups: gmane.lisp.guile.user Subject: Re: Need help embedding Guile Date: Tue, 21 Dec 2021 21:50:50 +0000 Message-ID: References: <2a789e248ef8d1922caec7af553cf26e9b360619.camel@telenet.be> Reply-To: Dimitris Papavasiliou Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="12895"; mail-complaints-to="usenet@ciao.gmane.io" Cc: "guile-user@gnu.org" To: Maxime Devos Original-X-From: guile-user-bounces+guile-user=m.gmane-mx.org@gnu.org Tue Dec 21 22:51:35 2021 Return-path: Envelope-to: guile-user@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mzn2k-00036R-UJ for guile-user@m.gmane-mx.org; Tue, 21 Dec 2021 22:51:34 +0100 Original-Received: from localhost ([::1]:34304 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mzn2i-0002uK-14 for guile-user@m.gmane-mx.org; Tue, 21 Dec 2021 16:51:33 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:59108) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mzn29-0002u9-EZ for guile-user@gnu.org; Tue, 21 Dec 2021 16:50:57 -0500 Original-Received: from mail-4316.protonmail.ch ([185.70.43.16]:42371) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mzn25-0003gu-VA for guile-user@gnu.org; Tue, 21 Dec 2021 16:50:55 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.ch; s=protonmail2; t=1640123450; bh=oDAtG3LFQn2QRhY/yVGSTzS4IvUamL0Ru++3CVQznEE=; h=Date:To:From:Cc:Reply-To:Subject:Message-ID:In-Reply-To: References:From:To:Cc; b=fK5S05bpHutKgeBGYMUtiD91BzMHJdLQqqs0vOCLwMSuHjuGe9bhnjVUB9KDj5Zq5 MTFqNtCw4FTCphcdzv2z63VhanazaBHeadrLXHAKGf1nE+q5tVIzkKxekbl7gNOQbP cyq6xz1mzh5V2qGIUqPh8vU/EvUbJccHk9XbUPYQlzfRF7NQRn0631YPvpBSJ5pkXS X+I2zrh4QTT2UUvZRx2MDhbX8dVzZ2KycLyZZeoDbWywsR3BFRE6VYOybFaiisNLKM FZJ0vAuI4bkyDn5Kexhk/yd1WOFnJIM9MEYfBy4Wxz423VBXzS5gSt5003XQcWQiH/ Jtc2sHxofJldA== In-Reply-To: <2a789e248ef8d1922caec7af553cf26e9b360619.camel@telenet.be> Received-SPF: pass client-ip=185.70.43.16; envelope-from=dpapavas@protonmail.ch; helo=mail-4316.protonmail.ch X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-user-bounces+guile-user=m.gmane-mx.org@gnu.org Original-Sender: "guile-user" Xref: news.gmane.io gmane.lisp.guile.user:17897 Archived-At: Hi Maxime, Many thanks for your response; it was very helpful. Unfortunately I'm now = not so sure that I have the basics of embedding Guile more or less working and,= even worse, I'm not really sure Guile is meant to work in the way I'm trying to = use it. The idea is that the C++ program, after some initialization, loads and eval= uates one or more Scheme files (provided by the user as command line arguments). During the course of their evaluation, these create objects on the C++ side (representing the work that is to be done) and, once they're evaluated the = work of Guile is done. At that point, ideally, I'd like to deinitialize/termina= te Guile, both to reclaim resources which are no longer necessary and to ensur= e that it plays no further role in the execution of the rest of the program. = As far as I can see, this is not possible. Furthermore, as you have pointed out, I cannot ensure that all created fore= ign objects are finalized. The idea here seems to be that some objects might h= ave still been reachable at the very end, as far as the GC can tell and, at any rate, will be reclaimed by the operating system when the process exits. Bu= t in my case, where the role of the embedded language, is restricted to the init= ial phase of the embedding program's execution, this not only needlessly remove= s control of these resources from the embedding program, they also show up as memory leaks in tools like MemorySanitizer and Valgrind, which is a big pro= blem in itself. Given the inability to tear down/kill Guile explicitly, I can't= see a way around this. That is not entirely true. I could perhaps keep track of objects that need= to be finalized myself, and finalize them manually after Scheme code evaluatio= n is done. This also seems to be what's recommended in one of the sources you quoted: On Tuesday, December 21st, 2021 at 1:37 PM, Maxime Devos wrote: > You do sometimes want to ensure that certain particular resources are > explicitly reclaimed before process exit, whether or not they become > unreachable. Programming techniques for ensuring this are discussed in > ``Destructors, Finalizers, and Synchronization'', Proceeedings of the > 2003 ACM SIGPLAN-SIGACT Symposium on Principles of Programming > Languages, Jan. 2003, pp. 262-272. Official version. Technical report > version. HTML slides. PDF slides. I'm still not sure I find this to be a satisfactory approach though. Not o= nly is it non-trivial in terms of implementation, it also feels like I'm going against the current, trying to bend Guile into a role it's not meant to ser= ve. > You can (set! the-global-variable #f) to clear the reference, > though still there are no formal guarantees BDW-GC will collect things. True. Furthermore, the Scheme code, being user-provided, could establish a= ny number of references in various ways. As far as I can see, there is no way= to completely "clear" an environment, i.e. remove all bindings contained in it= , or to somehow delete it altogether or communicate to the GC that is no longer reachable, so again I see no way around this. If anyone has any comments or ideas, they would be most welcome. Dimitris PS: > Due to bootstrapping reasons, there are multiple readers and evaluators > in Guile, of varying debugability. I'm not 100% sure, but I think > the 'primitive-load' reader+evaluator has low debugability and the > 'load' procedure has higher debugability? I'll leave diagnostics for later, perhaps for a different thread, as the ma= tters discussed above seem to be more serious (and potentially fatal).