Re: status and perceptions of luaproc

[Nagaev Boris <bnagaev@...>]

On Sat, Jul 25, 2015 at 12:40 PM, Mason Bogue <scythe+lua@ortsz.com> wrote:
> http://www.inf.puc-rio.br/~roberto/docs/ry08-05.pdf
>
> This library -- which seems to show that Lua can handle concurrent
> programming quite well -- doesn't appear to be maintained. That's
> unfortunate, because I don't know if the other solutions available
> replicate the advantages of luaproc, viz. performance and simplicity.
> The major alternative, Lua Lanes, doesn't seem to be terrifically fast
> and seems to have been in bugfix mode for two years (
> https://github.com/LuaLanes/lanes/commits/master ), while the
> commonly-accepted solution is to use llthreads with 0mq, and I have a
> hard time believing either of these even comes close to luaproc,
> performance-wise, considering that Skyrme et al went as far as to draw
> comparisons to Erlang while spinning up myriad fibers; Lanes' green
> threads are much heavier than fibers and its scheduler was good but
> not spectacular the last time I checked, whereas llthreads is 1:1, not
> M:N (thus a very different model).

(offtopic)

There is also llthreads2, `llthreads` library rewritten without
`LuaNativeObjects` code generator. It seems to be maintained.

https://github.com/moteus/lua-llthreads2

> I noticed this when I looked at luaproc a month ago and submitted a pr
> that fixes creating threads from pure Lua functions. Nobody said
> anything and I later realized that two other pull requests (of
> admittedly variable code quality) have been languishing for even
> longer. I'm not sure if Dr. Skyrme is simply away or doesn't want
> contributions via github.
>
> I'd also like to know the community's opinion on luaproc, and whether
> it's features are desirable or generally considered to be superseded
> by something of which I'm not aware. I could take over maintainership
> of the library resp. bugfixes and minor PRs (e.g. v5.3 / v5.4
> compatibility), but I don't have the time or energy to break new
> ground and would want to pass it off to someone else if development
> takes off for some crazy reason. One exception: it is missing yield(),
> kind of convenient for any fiber library, which I could add easily
> enough.
>



-- 


Best regards,
Boris Nagaev