Extend “core and auxiliary” libraries to “core, auxiliary and optional.” Core and aux to be ANSI-C _only_ (move shared library loading to optional). Include a range of popular (if not 100% portable) but PUC-endorsed libs in “optional.” Start with luasocket and consider luathread.

I’m not sure what authority he wrote that with, or if it was just a suggestion. I guess we won’t know what will be in 5.2 until it comes out .

The “mechanisms, not policies” mantra avoids tough decisions, of which concurrency brings many. A standard way to serialize data would be a step in the right direction, but there are many ways to do that as well.

For now, it’s certainly nice that the Programming in Lua book has examples of threading. I haven’t yet checked out LuaLanes, but it has me interested, at a conceptual level.

as much as i’d love to see this; i still haven’t seen any hit about that possibility.

maybe by the “mechanisms, not policies” mantra could there be an way to create a value reference from one Lua State to another? If that was possible, a LuaLane could ‘publish’ a value to be used from another Lane, with locking only on these cross-state accesses, not ALL accesses, like LuaThreads.

– Javier