RE: running LUA code step by step

[Sean Middleditch <elanthis@...>]

Hmm, that is an interesting approach.  I've slightly familar with
"fibers" (I've read about them, know their uses) but never actually used
them.

I'd go for it, but my problem is, I'm a portability freak.  I want to
see my software running on my x86 Linux boxes, future ia64 Win64 boxes,
and embedded OSes on embedded processors (Or, hell, just the umpteen
million architectures Linux supports).

So, while fibers could be ported to *most* major systems, there will be
those few it can't be.  Plus, it's a porting nightmare.

Again, I've been implementing and re-implementing my own languages for
about a year now, trying to get that at least has the "perfect" feature
set (for my needs), and have yet to get one to be completely
pre-emptible.  I know now what I have to do (a full byte-code machine,
with both the data and calls stored on stacks).  This is similar to how
Lua works, although calls aren't on the stack (last I read), although
I've seen a patch to do this.  I don't know if that's the yield patch or
not, tho.

On Fri, 2002-03-15 at 16:00, Curt Carpenter wrote:
> > I want Lua to be able to rune multiple chunks/states/threads/whatever,
> but be interruptible (to give control back to the controlling thread).
> 
> My solution, which requires 4.1:
> 
> In Windows, we have the concept of fibers--user scheduled execution
> contexts within a thread, each with their own stack. In my thread, I
> have a primary fiber, and a bunch of worker fibers. Fibers are extremely
> lightweight to switch, compared to threads, and you don't have to worry
> about making stuff thread safe. The main loop on the primary fiber looks
> like this:
> 
> 1) Fire up new fibers (and call lua_newthread) for new objects which
> need their own script execution/stack/lua_state
> 2) Keep a list of objects that are ready to execute. Loop over all
> objects and switch to their fiber.
> 3) In each object, figure out when they want to yield, either by a
> line/call hook, or by a call into a registered C function that indicates
> they need to wait (like a call that blocks on something out of its
> control).
> 4) When an object is ready to yield, switch back to the primary fiber.
> 5) Depending on your needs, have some plan to add objects back to the
> ready list. If you want all objects to execute code on every cycle, then
> maybe you don't need a ready list, but I use it to mark scripts that are
> ready to continue after having some condition met that they are blocked
> on.
> 
> Curt