Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

In your "See Also", you missed my favorite UV+Lua combination: https://github.com/richardhundt/luv/tree/ray (note the branch). It too uses the Lua coroutines but has a specially-built scheduler. How does this compare to that effort, specifically, how are the libuv event loop and the Lua coroutines combined?


Thanks for pointing that out. I was going to ask why it appears to have stalled a year ago, but I guess the author got distracted by something shiny:

https://github.com/richardhundt/shine

Shine appears to address a similar need as the luv "ray" branch, _without_ libuv, with a modified version of LuaJIT[1]. I wonder if the author plans to patch LuaJIT upstream?

A recent HN discussion[2] left me wondering where to look for a high-quality well-maintained lua "stdlib". luvit appears to be an entire distribution with its own package manager instead of luarocks/moonrocks. I'm now looking at luv and luajit-libuv. shine looks like a very interesting alternative, but the modified LuaJIT makes it problematic for deploying to users who want to use system-provided LuaJIT.

[1] https://github.com/richardhundt/shine#introduction

[2] https://news.ycombinator.com/item?id=8191345


I might be remembering it wrong, but iirc it so transpired that there was a thread on the Lua mailing list about the unfortunate clash in the name 'luv'.

richardhundt/luv is older of the two pieces of software but Richard graciously offered to yield (pun intended) the name to luvit folks and continued to develop on his code and ideas under a new name, shine. richardhundt/luv is more than an obvious wrapper over libuv whcih is what luvit/luv intended to be.

Please bear in mind I might have got the exact events (Gawd, pun again, this time unintended) wrong, but if you are interested you will be able to find this on the lua mailing list archives.


Thanks very much.


Thanks, I've added it to the list.

In luajit-libuv, when Lua code makes an async request to libuv, it passes async.resume as the callback. Then it calls async.yield(), which stores the current coroutine in a global lookup table by unique ID, puts the ID in the request's data field, and yields the coroutine. When libuv completes the request, it calls async.resume, which gets the ID out of the request's data field, looks up the coroutine, and resumes it. [1]

So it's actually pretty simple, and still probably more complicated than it needs to be. libuv does all the scheduling.

I've been studying Ray, going over luv_fiber.c and luv_thread.c trying to understand them enough to give you a comparison, but to be honest I don't get it. It wraps coroutines, does something related to scheduling... I dunno.

[1]: https://github.com/pguillory/luajit-libuv/blob/master/src/uv...




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: