guile-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Neil Jerram
Subject: Re: Long-lived Guile scripts in a mono-threaded game engine
Date: Tue, 27 May 2008 22:49:01 +0100

2008/5/27 Clinton Ebadi <address@hidden>:
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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]