lua-users home
lua-l archive

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

I haven't had a chance to look at the snapshot yet, but Lua-level coroutines are all that I would need. I just want to have an -official- way to do what Bret Mogilefsky did in GF way back when. Run a Lua-thread until it blocks or until it have executed a fixed number of opcodes, and then switch to the next Lua thread. Calls into C are treated as one atomic operation. It sounds like lua_newthread will support that easily, can't wait to give it a try (though I'll probably wait for an official release, unfortunately I don't have time to mess around with it right now :p ) As long as the task switch always takes place while the thread is in the
Lua VM it should work fine.

I don't think C-level coroutine support is a good idea, myself. Programs that need it should
(IMO of course) use a separate C library.


Jean-Claude Wippler wrote:

Edgar Toernig <> wrote:


I'll definitely take a look.  In Sol I already have a coroutine library
based on longjmp.  But it requires knowledge about the structure of the
jmp_buf.  I recently found the POSIX functions getcontext/makecontext/
swapcontext.  I'll change Sol's coro-lib to depend on these functions
and add a prototype ucontext implementation for systems that do not have
these functions [1].  I'll then port this lib to Lua 4.1.

Ouch.  C-level co-routines?  My first reaction was: why not simply
implement them at the Lua level?  Oh, of course: Lua intermingles the C
call stack with its own... like Tcl and standard Python - and unlike
Stackless Python (which implements "calling" without nesting the C
stack).  SP's trick is to have the VM push and pop call frames, instead
of going through a C function which nests the VM.

For Lua, this would require luaD_call to be split into two, and all
places where it gets called as well.  Quite a bit of surgery, unfortunately.

That's a pity.  If Lua were to avoid the C stack for ordinary function-
call nesting, then coroutines (at the Lua-level) would be easy to
implement - no special C code, and portable.  Simply a closure which
remembers the new_thread pointer, and saving/restoring the current VM
instruction pointer on that stack for suspend/resume.