lua-users home
lua-l archive

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

The bindings and libraries provided by lubyk would seem to be a good choice. I have been running apps (single lua state) with GUI callbacks (OpenGL), Wiimote data (bluetooth based serial com) and sockets, all in the same script.

In lubyk you have:

lk.Thread (OS threads, will ask for global lock when entering lua)
lk.Socket (releases lock on accept/recv)
zmq.Socket (releases lock on recv/send/etc)

The whole library is meant to run on Mac/Linux/Windows. A subset (no huge math lib, no graphical interface) will run in embedded linux. Some other objects that could be interesting:

mimas (Qt bindings)
cv (OpenCV bindings)
mdns (Zeroconf/Bonjour)
wii (Wiimote)
db.Stream (Simple multitrack recorder/playback based on sqlite3)

When you want many Lua states eventually distributed across many physical boxes collaborating (this is the goal in Lubyk), you use zmq:

push = zmq.Push()

push:send('hello', {a=1, b='more'})

----- other thread
pull1 = zmq.SimplePull('tcp://', function(...)
  -- do something with the messages

And then, when you no longer want to deal with IP and ports, you use mdns with lk.Service:

bob = lk.Service('Bob')

bob:notify('hello', {a=2, b='again'})

---- other thread/box
mary = lk.Client(function(...)
  -- do something with the messages

This is very resilient: you can restart any of these two beasts and it will reconnect.

Lubyk has still a long way to go and some things are currently broken (mimas due to a massive rewrite of the callback architecture in Qt bindings) but most of these lower level things already work pretty well, at least on Mac OS X.



On Sat, Aug 27, 2011 at 8:22 PM, Thijs Schreijer <> wrote:
Hi Stefan,

> Lua Lanes seems very neat for true multithreading. It separates each
> thread ("lane")'s data from the other threads' data. So you don't get
> the problems of a shared mutable state.

The lanes support states;

"Lua Lanes supports the following operating systems:
 - Mac OS X PowerPC / Intel (10.4 and later)
 - Linux x86
 - Windows 2000/XP and later (MinGW or Visual C++ 2005/2008)
The underlying threading code can be compiled either towards Win32 API or
Pthreads. Unfortunately, thread prioritation under Pthreads is a JOKE,
requiring OS specific tweaks and guessing undocumented behaviour. Other
features should be portable to any modern platform."

I intended to use it on embedded linux on ARM architectures, would that
qualify as "any modern platform"? (sorry for the probably stupid question,
but I'm a total noob on this stuff)