lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

> > 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
> 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
> ...etc...

There's a much, much simpler fix for this: Don't Do That, Then.

C and C++ do not support microthreads (I'll follow Edgar's advice
and stop calling them coroutines.) Using Lua as your script language
will not suddenly make C and C++ start supporting microthreads, no
matter what you do. But with the simple, obvious, fast implementation,
you can have excellent microthread support *In Lua*, with some
unfortunate but unavoidable restrictions in your C functions--namely
that a C function called from Lua, which calls back into Lua code
which might yield, must explicitly push its state and use a trampoline.
It sounds like a pain, except that in practice it almost never happens
anyway; by going with fibers you'd be eliminating huge practical
benefits in favor of almost purely theoretical ones.

[Sorry, I often tend to rant for no reason.]