Re: Long-lived Guile scripts in a mono-threaded game engine

["Neil Jerram" <neiljerram@googlemail.com>]

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

2008/5/27 Clinton Ebadi <clinton@unknownlamer.org>:

> You are pretty much doing what call/cc does, and so could
> straightforwardly rewrite the functions that cause scripts to freeze
> to capture the current continuation and schedule an event to resume
> this continuation when needed. So something like:
>
> (define (say-stop message)
>  (call/cc (lambda (k)
>             (%say-stop message k))))
>
> This might be worth trying and might perform well enough, but Guile's
> call/cc is fairly slow and heavyweight as it must copy the entire C
> stack.


The amount of the stack that needs copying could be reduced, though, by
putting a continuation barrier (scm_c_with_continuation_barrier) in the C
code shortly before it calls out to Guile.

Personally, I'd try the continuation approach.  I did something just like
this for a dayjob-related project, where a key objective was to make the
Scheme scripts as friendly-looking as possible to non-Scheme people.  I used
continuations to make it possible to write a script as a sequence of
apparently synchronous operations that were really asynchronous (i.e. send a
request somewhere, and wait for an asynchronous response).  It can be done
in such a way that the call/cc is hidden down in the infrastructure, and
script-writers never need to see it.

A complication in my case was that the C code was sensitive to unusual
return patterns.  So I also needed to use a continuation to protect the C
code; I can provide more detail about that if needed.

Regards,
        Neil

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