From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Clinton Ebadi Newsgroups: gmane.lisp.guile.user Subject: Re: Long-lived Guile scripts in a mono-threaded game engine Date: Tue, 27 May 2008 14:19:36 -0400 Message-ID: <87fxs3624n.fsf@unknownlamer.org> References: <20080526211900.GB14261@perso.beuc.net> <87fxs4yy89.fsf@gnu.org> <20080527083324.GA16693@perso.beuc.net> <87hccjnars.fsf@gnu.org> <20080527161445.GB18239@perso.beuc.net> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1211912423 6040 80.91.229.12 (27 May 2008 18:20:23 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 27 May 2008 18:20:23 +0000 (UTC) Cc: guile-user@gnu.org To: Sylvain Beucler Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Tue May 27 20:21:04 2008 Return-path: Envelope-to: guile-user@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1K13nA-0001J1-8F for guile-user@m.gmane.org; Tue, 27 May 2008 20:21:00 +0200 Original-Received: from localhost ([127.0.0.1]:35111 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1K13mO-0000b0-RA for guile-user@m.gmane.org; Tue, 27 May 2008 14:20:12 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1K13mL-0000aj-7O for guile-user@gnu.org; Tue, 27 May 2008 14:20:09 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1K13mI-0000aG-0l for guile-user@gnu.org; Tue, 27 May 2008 14:20:08 -0400 Original-Received: from [199.232.76.173] (port=60522 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1K13mH-0000aD-Uc for guile-user@gnu.org; Tue, 27 May 2008 14:20:05 -0400 Original-Received: from deleuze.hcoop.net ([69.90.123.67]:55023) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1K13mH-00075A-D9 for guile-user@gnu.org; Tue, 27 May 2008 14:20:05 -0400 Original-Received: from [71.65.238.103] (helo=localhost.localdomain) by deleuze.hcoop.net with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1K13m5-0004oH-0u; Tue, 27 May 2008 14:19:53 -0400 In-Reply-To: <20080527161445.GB18239@perso.beuc.net> (Sylvain Beucler's message of "Tue\, 27 May 2008 18\:14\:45 +0200") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) X-detected-kernel: by monty-python.gnu.org: Linux 2.6 (newer, 1) X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-user-bounces+guile-user=m.gmane.org@gnu.org Errors-To: guile-user-bounces+guile-user=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.user:6583 Archived-At: Sylvain Beucler 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