lua-users home
lua-l archive

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




On Friday, July 12, 2013, D. Matt Placek wrote:

On Fri, Jul 12, 2013 at 9:25 AM, Andrew Starks <andrew.starks@trms.com> wrote:

I wonder if you are not describing exactly our approach. 

The C thread receives an anchored Lua thread. The callback function is either a function or a coroutine. It passes a message into a queue. the queue needs locks because there are many C threads. We signal the queue manager, which is a coroutine running in main's OS thread and it removes all of the messages and processes.   

Someone, somewhere has to manage a mutex to a message cue. No?

It may be a very similar approach.  The only queue in contention between the threads for me is used just as a list of lua function callbacks to wake up coroutines waiting on i/o, so it's not really a "message" queue (not used to pass data), just a list of i/o "event ready" notifications essentially.  That list has to be thread safe, but in our case we use a simple lock-free stack rather than mutexes.
 
Matt

Matt,

In looking at the lua source, it seemed like any table access would require locking (lua_lock). Also, is the stack filo?