Re: Low-Level Concurrency library

[Andrew Starks <andrew.starks@...>]

On Wednesday, January 15, 2014, D. Matt Placek <atomicsuntan@gmail.com> wrote:

On Tue, Jan 14, 2014 at 10:03 AM, Andrew Starks <andrew.starks@trms.com> wrote:

Lanes is awesome work. However, this is an example of something that is at a higher level than what I was thinking. For example (and as far as I could tell from looking at Lanes), it uses its own message passing functions. We have a desire to stick with nanomsg (or similar), in order to achieve network transparency. This will lead to other issues (endianness, byte alignment), of course.

I'll take another look at Lanes, however. It is an interesting project.

The complexity of sharing values between states is why I prefer a concurrency strategy that primarily uses coroutines.  Where I have blocking I/O I will use a separate thread and use lanes/lindas to transfer the data in as raw a form as practical to/from a coroutine in my primary lua state.  By moving all blocking operations to separate threads/lanes, the coroutines in the main state are always responsive and low latency.  Keeps things much simpler.  Of course, that doesn't help with network transparency or if you really need multiple threads to take advantage of multiprocessor bandwidth.

This strategy describes my approach perfectly. I use coroutines when I need to express concurrency, managing state machines/state change processing, etc.

OS threads on come into play when the real-time hardware API requires the threading. Also, we're supporting presentation processing across machines, as well. 

This is what I meant when I said that we're using Lua as the thread logic. Where there is a thread, there to you will often find lua_newstate.