Re: [ANN] luaproc 1.0-4

[Hisham <h@...>]

Hi! Congratulations on the release!

On 4 October 2015 at 18:28, Alexandre Skyrme <askyrme@inf.puc-rio.br> wrote:
>>
>> luaproc is a concurrency library for Lua, it allows multiple independent
>> execution flows of Lua code (Lua processes) to be executed in parallel.

What versions of Lua are supported? It would be nice to have it in the
announcement/README.

>> It is available at:
>>
>>   https://github.com/askyrme/luaproc
>>
>> This is version 1.0-4. It supports Lua processes as arguments to create
>> new Lua processes - previously it only supported Lua code strings - and
>> fixes a few bugs.
>
> Sorry, the last paragraph should have read:
>
> This is version 1.0-4. It supports Lua **functions*** as arguments to
> create new Lua processes - previously it only supported Lua code strings -
> and fixes a few bugs.

What happens when functions have upvalues?

And, on a tightly related note, do you have any recommendation for
serialization libraries? From this discussion on lua-l [1] there seem
to be a number of options, apparently including ones that serialize
upvalues.
[1] http://lua-users.org/lists/lua-l/2015-08/msg00082.html

If I'd have to use a serialization library anyway to send my data
around, it would be weird to have greater restrictions when creating
proc (if luaproc.newproc() uses a plain string.dump) than when passing
data through channels (if I use a serialization library able to encode
functions with upvalues).

If upvalues are not meant to be handled by newproc, it would be great
if the luaproc API detected their presence and raised an error. I
suspect using upvalues "accidentally" would be common (e.g, by writing
something like `local print = print` at the top of the module), and it
wouldn't be nice if that value was silently demoted to nil in the proc
and its use failed later on runtime.

In any case, as I told you in our last conversation in person, I think
a complete solution for concurrent programming necessarily involves
something like processes/channels (luaproc) + serialization, and from
what I gather, the lack of direction on how to take on the second half
of the problem leads people to fragmented, homegrown solutions, each
with different caveats (as seen above in [1]).

If luaproc won't bundle a serialization library (like Lanes and Tiago
Salmito's CLP [2] do — in fact, CLP reuses Lanes's serialization
code), what I would like to see, as a user (and which I think is the
best option, in fact), would be for luaproc to pick one existing
serialization library and specify it as a default dependency.
[2] https://github.com/salmito/clp

Those wanting different serialization libraries will always still have
the option to serialize data themselves and send strings around, but
having luaproc be a complete solution for concurrency would be great.
Any choice of serialization library is fine, as all have their
caveats, but having them to be well-known and the integration featured
in the examples tested to work with luaproc would make the pair a much
more attractive option than coming up with
yet-another-serialization-library (or yet-another-pthreads-wrapper).

If I have to dig through 5 different serialization libraries to see
which one works best, at one point I'll just say "look, all I want* is
to pass around this array of numbers, I'll just serialize them by hand
here**"
* ...for now (and as I add more and more features, before I notice I
have yet another serialization library)
** and then I'll split them on the other side, of course writing the
3528th version of string.split() ever written

A side note: it seems you are using the rockspec revision (the part
after "-") as part of your version number. The idea for that field is
to store changes in the rockspec itself, not in the code. Most
LuaRocks users will look at "1.0-3" and "1.0-4" and think they point
to the same codebase, with build/dependency/metadata fixes in the
rockspec only. Please make the next release someting like 1.0.5-1 or
1.1.0-1, if you're going for x.y.z numbering. LuaRocks does not
dictate semantic meaning for the version number (only to the rockspec
revision), so any numbering is fine, as long as they are increasing
(and just to be clear, for LuaRocks, 1.10 > 1.9).

-- Hisham