status and perceptions of luaproc

[Mason Bogue <scythe+lua@...>]

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).

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.