Guile library behaviour

Guile library behaviour

[Daniel CAUNE]

[-- 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 --]

Re: Guile library behaviour

[Lynn Winebarger]

On Wednesday 17 April 2002 03:15, Daniel CAUNE wrote:
> 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)?
> 
   Dynamic unload?  
   The garbage collector absolutely must know where the bottom of the
stack is to do its job.  You don't "initialize" guile and then do something,
you hand it your real main function and don't return until you're ready to
exit.  
    The only other way would be if someone modified guile to allow passing
in the bottom of the stack as initialization.  In the multi-threaded
case, it would have to know the bottoms of all the stacks, but I really don't
know what the status of guile's win32 thread support is, if any.  
     The other issue that would remain is that the garbage collector can't
be removed until it knows everything it's responsible for collecting has
been collected.  
      There might be other issues as well.

Lynn

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: Guile library behaviour

[Rob Browning]

Daniel CAUNE <danielc@in-fusio.com> writes:

> 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!

If I understand your problem/question it sounds like you were
expecting to call gh_enter (or scm_boot_guile) to initialize guile and
then have the function return so you can do other things.  If so, this
isn't how these functions work.  Check the info pages, but these
functions expect you to hand them your "real main function", one whose
return indicates the termination of the app just like returning from
main() normally does.

The original reason for this is just as Lynn explained it -- this used
to be the only way guile could portably find the bottom of the stack.
Also note that as things stand now, you can only run one copy of guile
inside any given app.

In general, if you're the one designing the app, the requirement that
guile be handed your real main function isn't a big deal, but in some
cases this isn't possible.  Fortunately, in more recent versions of
guile, clever people have figured out a fairly portable way to find
the bottom of the stack, and so on those platforms, you can use
scm_init_guile, which will return, and then you can go do whatever
else you want in your code.

Hope this helps.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: Guile library behaviour

[Daniel CAUNE]

[-- Attachment #1: Type: text/plain, Size: 2700 bytes --]

I understand what you mean. I think the Guile library doesn't to fit the
requirements of my server application. This application provides the
following features: 

o load and unload script interpreters' dynamic libraries (all these
libraries implement a specific interface) on client application demand; 
o execute a given script code on one of the loaded script intepreters. 

The code script interpreter mustn't take the hand on my application's
thread for ever, and it mustn't stop my process when a client
application sends a request to the server so that it unloads the script
interpreter's library. So I'm afraid I won't be able to use the Guile
library, even if it was so easy to integrate to my project. 

Thanks for you support. 


Daniel 


Le mer 17/04/2002 à 17:07, Rob Browning a écrit :

    Daniel CAUNE <danielc@in-fusio.com> writes:
    
    > 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!
    
    If I understand your problem/question it sounds like you were
    expecting to call gh_enter (or scm_boot_guile) to initialize guile and
    then have the function return so you can do other things.  If so, this
    isn't how these functions work.  Check the info pages, but these
    functions expect you to hand them your "real main function", one whose
    return indicates the termination of the app just like returning from
    main() normally does.
    
    The original reason for this is just as Lynn explained it -- this used
    to be the only way guile could portably find the bottom of the stack.
    Also note that as things stand now, you can only run one copy of guile
    inside any given app.
    
    In general, if you're the one designing the app, the requirement that
    guile be handed your real main function isn't a big deal, but in some
    cases this isn't possible.  Fortunately, in more recent versions of
    guile, clever people have figured out a fairly portable way to find
    the bottom of the stack, and so on those platforms, you can use
    scm_init_guile, which will return, and then you can go do whatever
    else you want in your code.
    
    Hope this helps.
    
    -- 
    Rob Browning
    rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
    Previously @cs.utexas.edu
    GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD
    

[-- Attachment #2: Type: text/html, Size: 5021 bytes --]

Re: Guile library behaviour

[Daniel CAUNE]

[-- Attachment #1: Type: text/plain, Size: 2076 bytes --]

Oups, sorry! I've sent my answer too quickly! Can you tell me which
version of the Guile library that implements the scm_init_guile?

Daniel

Le mer 17/04/2002 à 17:07, Rob Browning a écrit :

    Daniel CAUNE <danielc@in-fusio.com> writes:
    
    > 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!
    
    If I understand your problem/question it sounds like you were
    expecting to call gh_enter (or scm_boot_guile) to initialize guile and
    then have the function return so you can do other things.  If so, this
    isn't how these functions work.  Check the info pages, but these
    functions expect you to hand them your "real main function", one whose
    return indicates the termination of the app just like returning from
    main() normally does.
    
    The original reason for this is just as Lynn explained it -- this used
    to be the only way guile could portably find the bottom of the stack.
    Also note that as things stand now, you can only run one copy of guile
    inside any given app.
    
    In general, if you're the one designing the app, the requirement that
    guile be handed your real main function isn't a big deal, but in some
    cases this isn't possible.  Fortunately, in more recent versions of
    guile, clever people have figured out a fairly portable way to find
    the bottom of the stack, and so on those platforms, you can use
    scm_init_guile, which will return, and then you can go do whatever
    else you want in your code.
    
    Hope this helps.
    
    -- 
    Rob Browning
    rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
    Previously @cs.utexas.edu
    GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD
    

[-- Attachment #2: Type: text/html, Size: 4367 bytes --]

Re: Guile library behaviour

[Daniel CAUNE]

[-- Attachment #1: Type: text/plain, Size: 2475 bytes --]

I answer to my question: version 1.5.

Does somebody has already made a win32 dynamic link library with the
Guile source 1.5, so that I can use easily?... ;-)


Le mer 17/04/2002 à 17:21, Daniel CAUNE a écrit :

    Oups, sorry! I've sent my answer too quickly! Can you tell me which
    version of the Guile library that implements the scm_init_guile? 
    
    Daniel 
    
    Le mer 17/04/2002 à 17:07, Rob Browning a écrit : 

        Daniel CAUNE <danielc@in-fusio.com> writes:
        
        > 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!
        
        If I understand your problem/question it sounds like you were
        expecting to call gh_enter (or scm_boot_guile) to initialize guile and
        then have the function return so you can do other things.  If so, this
        isn't how these functions work.  Check the info pages, but these
        functions expect you to hand them your "real main function", one whose
        return indicates the termination of the app just like returning from
        main() normally does.
        
        The original reason for this is just as Lynn explained it -- this used
        to be the only way guile could portably find the bottom of the stack.
        Also note that as things stand now, you can only run one copy of guile
        inside any given app.
        
        In general, if you're the one designing the app, the requirement that
        guile be handed your real main function isn't a big deal, but in some
        cases this isn't possible.  Fortunately, in more recent versions of
        guile, clever people have figured out a fairly portable way to find
        the bottom of the stack, and so on those platforms, you can use
        scm_init_guile, which will return, and then you can go do whatever
        else you want in your code.
        
        Hope this helps.
        
        -- 
        Rob Browning
        rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
        Previously @cs.utexas.edu
        GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD
        

[-- Attachment #2: Type: text/html, Size: 4985 bytes --]

Re: Guile library behaviour

[Lynn Winebarger]

On Wednesday 17 April 2002 10:07, Rob Browning wrote:
> The original reason for this is just as Lynn explained it -- this used
> to be the only way guile could portably find the bottom of the stack.
> Also note that as things stand now, you can only run one copy of guile
> inside any given app.
> 
> In general, if you're the one designing the app, the requirement that
> guile be handed your real main function isn't a big deal, but in some
> cases this isn't possible.  Fortunately, in more recent versions of
> guile, clever people have figured out a fairly portable way to find
> the bottom of the stack, and so on those platforms, you can use
> scm_init_guile, which will return, and then you can go do whatever
> else you want in your code.

   Mea culpa.  They are clever, that's for sure.  The heuristic that
crawls up the stack until it causes a segmentation fault or bus error
- that's the good stuff.

Lynn

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user