lua-users home
lua-l archive

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


Hey,

How you'd go about it would depend on how seamless you want it to be. If you don't mind losing the concurrent processing of futures, future's could easily be added via tables, userdata or a custom type, with minimal changes to the lua c code. (Would have to change the comparison code, arithmetic handling could easily be implemented via metamethods). Wouldn't be hard at all to do, and who knows might save the odd clock cycle when a value is computed but never required, along with making good proof of concept. (Of course on the stack the value would stay as a table, but you'd make it so the value is stored away once the function has completed, making its access quick).

To allow concurrency would be hard work. You could simulate it a bit by representing futures with coroutines, with a coroutine dispatcher thread, and each future/main thread yielding at key points - but it's a bit unwieldy for this purpose. Would appear completely multithreaded though, with expensive functions not blocking the code. And has the advantage that when a good make-coroutines-concurrent patch comes along, it'd all work beautifully.

Or if hung up on true concurrency now, could try representing futures as userdata, with each userdata spawning a whole new lua state. You'd have no access to globals, etc (but then how do these work in "futures"?), but there'd be no inherent problems in running each state in its own thread. Very expensive though.

To improve on that (concurrency within a lua state) would require everything that simultaneous coroutines requires, so there isn't much point. Perhaps look to lua lanes (which I believe defines global locks around pretty much every lua function).

I'll be interested to see what you come up with though :).

- Alex