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