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

[Clinton Ebadi <clinton@unknownlamer.org>]

Sylvain Beucler <beuc@beuc.net> writes:

>> IOW, `say_stop' does a `(sleep 2)' (or `sleep (2)'), or waits for some
>> UI event, is that right?
> ---
>> what is the nature of the pause? (I think that that might be important.)
>> How do you interrupt the tight little say_stop sleep loop (if that's what
>> it is) when you are using C bindings?
>
> Basically, a timestamp (for 'say_stop' and 'wait') or more generally a
> goal (coordinates for 'move_stop') is attached to the script. The game
> loop, before refreshing the screen, passes on each active script and
> see if it needs to be resumed.
>
> If at a point the engine needs 3s to load a bunch of graphics and
> sounds from the disk (e.g. during a screen change), the paused script
> won't wake up during that, but instead will be awaken by the engine
> when it's done with the loading.
>
> So the script does not (sleep). In this game, the engine is a mini-OS
> with a non-preemptive process model. This is often used in games for
> efficiency and ease of debugging (no concurrency). In my case this is
> because the code was like this before I put my hands on it :)
>
> Currently when the script engine interprets 'say_stop("Hello");', it
> will set the timestamp at now+2s, save the script resume point, and
> return to the main game loop.

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.

An alternative approach could use a thread per script. You'd stash the
thread you want to resume into the event, put it to sleep immediately,
and awaken it again when the event triggers. This would probably be
fairly easy to implement using condition variables. The disadvantage
here is that now every script has a thread which could become
problematic if enough scripts are loaded.

-- 
                   It's no contest, but we still race there                   
                Like the saintly tortoise and the godless hare