RE: cooperative multitasking

[Sean Middleditch <elanthis@...>]

On Fri, 2002-06-07 at 15:43, Curt Carpenter wrote:
> > Ah, I see.  Maybe in another year or two then when no console would
> show it's face without 128/256MB of RAM... ~,^
> 
> Doubtful. Anyway, I forgot to say I am only using them on the server
> (yes, for a game), not on the client.

Ya, my current projects are limited to server only, but I'd like the
script engine to be portable to clients.

> 
> > Hmm, in what I've worked on, a thread switch in the script engine
> could be as fast as changing a pointer
> 
> The limitation is when you have a call into a registered function, and
> you want it to block and return control to your "normal" non-Lua C code.
> At that point you have a call stack that looks something like this:
> 
> MyRegisteredFunction
> luaD_precall
> luaV_execute
> luaD_call
> f_call
> luaD_runprotected
> lua_call

Like I said, I know what a pita it is.  Which is why I was wondering
about the fibers.  I can think of two non-fiber ways of handling it
properly - let there be nested scheduler calls - so long as the stack
doesn't descend too deeply, there won't be a problem, but it still
leaves room for the script to crash the server (which I think should be
as impossible as possible - and boy did that just sound weird...)

> 
> So with a fiber, all that stays as is, you switch to your C code, and
> switch back when you like, and when you do that stack is still exactly
> as it was. With a coroutine, if you want to yield
> _but_not_to_another_Lua_thread_, you have to unwind all that, and wind
> it back up when you resume it, and you have to write your registered
> functions such that they return, even when blocked. With fibers you can
> block in a synchronous way, thus doing work in the function after being
> unblocked, but before returning to Lua. Again, I'm sure it's not for
> everyone, but it has been a useful approach for me, so maybe it is for
> someone else too.

Ya, like I said, I've seen it used a lot, especially in some more
"industrial strength" languages, but not in anything as lite-weight as
Lua.

Does your C functions deal with OS threads at all?  If so, would fibers
possibly cause race conditions/dead-locks in regards to mutexs and
whatnot (or whatever your platform uses for synchronization)?

> 
> Curt