unofficial mirror of guile-user@gnu.org 
 help / color / mirror / Atom feed
From: Maxime Devos <maximedevos@telenet.be>
To: Dimitris Papavasiliou <dpapavas@protonmail.ch>,
	"guile-user@gnu.org" <guile-user@gnu.org>
Subject: Re: Need help embedding Guile
Date: Tue, 21 Dec 2021 11:37:45 +0000	[thread overview]
Message-ID: <2a789e248ef8d1922caec7af553cf26e9b360619.camel@telenet.be> (raw)
In-Reply-To: <B06KtohfOgQJEKiyjWFF902QowT8UGx6Nqmj7JFZsUjsVUlu0N6AwZ3fRP3pwSkmmm4eo22sa2cm8jx7Ye_4j-QsW2YSnYMM3Jilu00Piv4=@protonmail.ch>

Dimitris Papavasiliou schreef op di 21-12-2021 om 11:12 [+0000]:
> [1...]

> . The manual is not very specific about how and when finalizers are
> run.  The
>    approach above seems to correctly finalize all objects created as
> the Scheme
>    code executes, but if references are kept, say via (define), they
> are not
>    finalized and I get memory leaks.  Is there some way to arrange
> for the
>    complete deinitialization of Guile after I've finished evaluating
> Scheme code
>    and making sure that all finalizers are run?

The manual is not very specific on when finalizers are run, because
there aren't many formal guarantees (e.g., BDW-GC is a conservative GC,
so it might think an object is not finalizable even though it is).

About deinitialising guile: I don't know.
About finalizers: No. From the BDW-GC faq:

 I want to ensure that all my objects are finalized and reclaimed
before process exit. How can I do that?

You can't, and you don't really want that. This would require
finalizing reachable objects. Finalizers run later would have to be
able to handle this, and would have to be able to run with randomly
broken libraries, because the objects they rely on where previously
finalized. In most environments, you would also be replacing the
operating systems mechanism for very efficiently reclaiming process
memory at process exit with a significantly slower mechanism.

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. 

> 2. If, in `run_body', I simply do
> 
>        scm_c_primitive_load(context->input);
> 
>    then the code is evaluated, but on error I get no locations in the
> stack
>    trace.  The error is said to have occurred "in an unknown file"
> with no line
>    numbers.  Evaluating `load' as shown above, seems to produce
> proper source
>    locations in the stack trace.  Is there something else I should be
> preferably
>    doing?

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?

> 3. More generally, is there a preferable way to go about embedding
> Guile for my
>    use case?

Instead of reinitialising and deinitialising guile repeatedly (seems
inefficient!), I would suggest initialising Guile once at program start
and do Guile stuff whenever needed.

However, that might be incompatible with your memory management
approach ...

Greetings,
Maxime.




  reply	other threads:[~2021-12-21 11:37 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-21 11:12 Need help embedding Guile Dimitris Papavasiliou
2021-12-21 11:37 ` Maxime Devos [this message]
2021-12-21 13:45   ` Maxime Devos
2021-12-21 13:48   ` Maxime Devos
2021-12-21 21:50   ` Dimitris Papavasiliou
2021-12-21 22:39     ` Olivier Dion via General Guile related discussions
2021-12-22 11:41       ` Dimitris Papavasiliou
2021-12-22 13:52         ` Thien-Thi Nguyen
2021-12-22 22:05           ` Dimitris Papavasiliou
2021-12-22 14:46         ` Olivier Dion via General Guile related discussions
2021-12-22 15:23           ` Maxime Devos
2021-12-22 15:29         ` Maxime Devos
2021-12-22 22:14           ` Dimitris Papavasiliou
2021-12-22 17:37         ` Mikael Djurfeldt
2021-12-23  9:40           ` Mikael Djurfeldt
2021-12-29 16:26           ` Olivier Dion via General Guile related discussions

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=2a789e248ef8d1922caec7af553cf26e9b360619.camel@telenet.be \
    --to=maximedevos@telenet.be \
    --cc=dpapavas@protonmail.ch \
    --cc=guile-user@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).