Re: Need help embedding Guile

[Dimitris Papavasiliou <dpapavas@protonmail.ch>]

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 evaluates
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/terminate
Guile, both to reclaim resources which are no longer necessary and to ensure
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 foreign
objects are finalized.  The idea here seems to be that some objects might have
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.  But in
my case, where the role of the embedded language, is restricted to the initial
phase of the embedding program's execution, this not only needlessly removes
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 problem
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 evaluation 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 only
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 serve.

> 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 any
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 matters
discussed above seem to be more serious (and potentially fatal).