Re: incompatibilities to 5.0 beta

["C.S. Brooks" <chrisb@...>]

I've written a coroutine scheduler (a modified version of the one someone
posted here a while ago (thanks!)). In it, the scheduler notices that a
coroutine has finished by, as you say, noting what happens the *next* time
it tries to resume that coroutine. (What happens is that the return from the
wrapper function is a magic string, something like "coroutine can't
resume".)

What I'm thinking is that one coroutine might want to know when another has
"return"ed, so it can wait for that coroutine to have finished whatever task
it was supposed to do. Though I can do that by having some agreed-upon
variable that the returning coroutine sets or something like that, the
cleanest way seems like the waiting coroutine just checking
"othercoroutine.status".

Also, in my application (a computer game), each cycle through the scheduler
corresponds to a frame being rendered on-screen. So having a coroutine have
to wait an extra frame to know that another finished won't work in general,
as, for example, a sprite onscreen might flash for a frame as a result.

Anyway, regardless, thanks for the info! Coroutines, and their
implementation in lua, have really made it feasible for us to throw out the
custom scripting language I created and used in a previous game, and use lua
instead. We're currently writing all our game-specific code in lua, and
everything in C++ is non-game-specific, and it's working out great, and
should save a ton of dev. time.

--
C.S. Brooks
Professor Fog's Workshop
http://www.fogsworkshop.com


----- Original Message -----
From: "Roberto Ierusalimschy" <roberto@inf.puc-rio.br>
To: "Multiple recipients of list" <lua-l@tecgraf.puc-rio.br>
Sent: Thursday, November 21, 2002 9:34 AM
Subject: Re: incompatibilities to 5.0 beta


> > But: is there any way to tell if a coroutine returned returned due to a
> > yield, or due to a "return"? (I mean a generalized way, that doesn't
depend
> > on the function "return"ing a special value.)
>
> No. (Although you can find out the next time you try to resume it.)
> Maybe we will add something like "coroutine.status" that tells whether
> a coroutine is still active, but we are still waiting for "realistic
> examples".
>
> -- Roberto
>