Re: C++ religious war (was: llua Higher-level C API for Lua)

[Coroutines <coroutines@...>]

On Fri, Mar 21, 2014 at 7:47 PM, Andrew Starks <andrew.starks@trms.com> wrote:
> On Fri, Mar 21, 2014 at 1:55 PM, steve donovan
> <steve.j.donovan@gmail.com> wrote:
>> Having that kind of straightforward concurrency in Lua would be a
>> fantastic thing.
>
> I think this  is the next "64 bit integer" for Lua.
>
> 1: The rise of the "app store" created a compelling need to maintain
> code bases in ObjectiveC, Java and .Net. This is difficult to do for a
> 2 dollar app that may not sell and so we have Corona and many others.
>
> 2: The mobile space has many asynchronous requirements, in addition to
> the multiple cores that (i think) all devices now have.
>
> I think fantastic concurrency in Lua is pretty close to "present", as
> long as you stick to the "one state per thread". Maybe the language
> lacks some keywords (await?), but coroutines seem to cover my bases.
>
> I come back to my question from long ago: How could Lua evolve to
> further support this use case?
>
> The use case might be stated: "A language that sits on top of a
> native/system language *for the purpose of replacing the application
> code that would normally be written in that language.*"
>
> Of course much improvement could be achieved through library code. In
> order for library code to have  a significant impact, I believe that
> the libraries have to look like Lua: very small and simple. There
> aren't enough people that want to embed Lua and are also willing to
> package a large opaque library in order to achieve something that they
> see as basic.
>
> Some individual libraries that I think would help:
>
> timer: (sleep, nano-timer)
> A simple library that accesses the native os's high performance timers.
>
> poll/select
> A "poll" or "select" library that used the native environment's
> best-equivelent. I know that this is hard, but if one is trying to
> achieve the ability to catch file / socket i/o, there should be a
> library that other library authors use. LuaSocket does this (as well
> as sleep), and even makes it easy to integrate with other libraries.
> But it is not insignificant that I need to load LuaSocket to use it
> and it only supports select on Windows. IO Completion ports would be
> much better.
>
> thread
> llthreads2, but fixed. This library doesn't need to support every
> possible conception of threading. What llthreads2 does is probably
> enough, IMHO
>
> xmove, but for transfer between lua_states
>
> I know that in the Luaverse, there are tools that do all of these
> things. My point of emphasis is that individual libraries are better
> than fully baked solutions and some well done, simple tools might make
> a big impact.
>
> Not that Lua isn't already successful in that space.
>
> -Andrew
>

1) luasocket has that timer but is quite a dependency :(
2) We do need an alternate form of lua_xmove() to move data between
global_State's.  lua_State's are the execution context, the stack --
global_State's contain the data of the Lua instance.  lua_States
reference the internal global_State.  (sfaik)  With it we could set up
shared memory segments and exchange data between concurrently running
Lua instances -- channels without marshalling/serialization.
2) We need better libevent bindings (which I've been working on).  It
does a good job of using the best interface on the OS you're using --
I want to make it work with Lua file handles, as my socket library
also represents sockets as Lua file handles.  Also, it *must* be
libevent bindings if you want portable edge-triggering, as libev only
allows for level triggering.

Over and out ~