unofficial mirror of guile-user@gnu.org 
 help / color / mirror / Atom feed
From: ludo@gnu.org (Ludovic Courtès)
To: guile-user@gnu.org
Subject: Re: Trigger action at exit?
Date: Tue, 04 Mar 2008 11:25:50 +0100	[thread overview]
Message-ID: <874pbm3hw1.fsf@gnu.org> (raw)
In-Reply-To: 87d4qba1vs.fsf@ossau.uklinux.net

Hi,

Neil Jerram <neil@ossau.uklinux.net> writes:

> I agree that any main program should be able to handle its own cleanup
> using dynamic-wind.  What about a library, though?

Yes, you're right, and that's exactly what happens with John's "TAP"
modules.

At the same time, registering an `atexit' function from within the TAP
module seems inelegant: it assumes that the TAP module is used by
standalone programs only, and that exactly one Guile process is used for
each test that uses the module.  If you decide to use a single process
to evaluate all the tests, the `atexit' trick no longer works.

To me, it would look better if each test case had to insert, say, a
`(finish-test)' call at its end, even if it adds more lines.  That's
roughly what happens with SRFI-64: `test-end' must be invoked and in
addition, you may want to finish your standalone scripts with something
like `(exit (= (test-runner-fail-count (test-runner-current)) 0))'.

> In what sense fragile?

As in the example above, for instance.

More generally, `atexit' hooks are used only for their side effects, so
the order in which they are invoked is crucial.  However, it may often
be hard to know exactly in what order or when a given hook will be
called, because you don't necessarily know what hooks have been
registered.

Not to mention the interaction with the C `atexit', `on_exit', `exit',
`_exit', etc.

Now, I'd like to see why/how AutoGen uses it.

Thanks,
Ludovic.





  reply	other threads:[~2008-03-04 10:25 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-29 22:30 Trigger action at exit? John Trammell
2008-03-02 17:25 ` Ludovic Courtès
2008-03-03 20:44   ` Neil Jerram
2008-03-03 21:53     ` Ludovic Courtès
2008-03-03 22:17       ` Neil Jerram
2008-03-04 10:25         ` Ludovic Courtès [this message]
2008-03-04 17:03           ` John Trammell
2008-03-05 21:14           ` Neil Jerram
2008-03-03 21:22   ` John Trammell
2008-03-03 21:40     ` Ludovic Courtès
2008-03-03 22:27       ` John Trammell
2008-03-05 21:27         ` Neil Jerram

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=874pbm3hw1.fsf@gnu.org \
    --to=ludo@gnu.org \
    --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).