From: Daniel CAUNE <danielc@in-fusio.com>
Subject: Guile library behaviour
Date: 17 Apr 2002 10:15:57 +0200 [thread overview]
Message-ID: <1019031358.3287.68.camel@tedy> (raw)
[-- Attachment #1: Type: text/plain, Size: 2375 bytes --]
Hi,
Last night I went deeper in the Guile library code and I saw the reason
of my application server shutdown. After invoking the gh_enter function,
the first function that is called after the Guile initialization is the
function gl_launch_pad, which calls my own function and then calls the
exit system function. Then all my application server shutdowns!
I can replace this gh_launch_pad by my own launcher function, but I
think my problem'll stay the same since the scm_boot_guile also calls
the exit system function when ending. The code documentation explains
that "(...) scm_boot_guile function exits, rather than returning, to
discourage people from making that mistake.". "Yes, I see", to use the
favorite reply of Ryo Hazuki !
I don't clearly understand the main idea of the Guile library
initialization design. How can use it in an application that must be
independent from a script interpreter (dynamic load and unload)?
Any ideas?
Daniel
>Hi,
>
>I'm encountering some problems with a development at home of a small
>server application in C++ using the Guile dynamic libraries for the
>Windows platform, included in the file guile-1.4.zip downloaded from
>http://www.textsure.net/~ela/download/.
>
>One of my application's thread dynamically loads the Guile library
>(dynamic binding) and calls the gh_enter function (i.e. scm_boot_guile)
>to initialize the Scheme interpreter, and then... all the application's
>process shutdowns brutally! I was a bit confused, so I've developped a
>mono-threaded application to test this Guile library (static binding),
>and it rocks!
>
>So I've trie to investigate further, debugging the assembly code of the
>Guile library called by my server application code (this library
doesn't
>include debug information, but I get the Guile source files from GNU
web
>site), and trying to understand where it sucks.
>
>I've followed my instruction pointer until the scm_internal_lazy_catch
>code (throw.c) where I lost it, my baby crying and asking for her milk
>in the darkness of the night... Return to the reallity! I'll certainly
>continue my quest tonight, but I would prefer that a valiant knight, or
>a magician, gives here the exact reason of my trouble, if he've already
>encountered it.
>
>Thanks!
>
>
>Daniel
>
>________________________________________
>"Thuong nhau qua, can nhau dau..."
[-- Attachment #2: Type: text/html, Size: 2972 bytes --]
next reply other threads:[~2002-04-17 8:15 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-04-17 8:15 Daniel CAUNE [this message]
2002-04-17 12:14 ` Guile library behaviour Lynn Winebarger
2002-04-17 15:07 ` Rob Browning
2002-04-17 15:19 ` Daniel CAUNE
2002-04-17 15:21 ` Daniel CAUNE
2002-04-17 15:35 ` Daniel CAUNE
2002-04-30 4:29 ` Lynn Winebarger
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=1019031358.3287.68.camel@tedy \
--to=danielc@in-fusio.com \
/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).