Yep, I'm currently rewriting luv to use the latest libuv version. There have been a *lot* of breaking changes in libuv. But the good news is the new version should be around for a while and it being tagged 1.0.0 upstream with semver API/ABI stability promises.
The new luv code (in https://github.com/luvit/luv/tree/uv-update-1.0.0) uses a simpler model for memory management. The libuv structs are passed directly to lua as userdata values. There is no wrapper struct. Rather I'm using the void* data member of all libuv objects to create a tiny luv managed struct containing lua_State and a couple refs (to the userdata and it's current lua_State) to prevent GC eating things before libuv is done. I create the userdata ref upon userdata creation and don't free it till userdata close callback. This means you'll leak lua memory if you never close your objects, but since you'll leak memory on the libuv side anyway if you forget to close them, I don't see that as an issue. Also using uv.walk, you can get a reference to all the active objects in a loop. I might be able to add some sort of multithreading so that you can have multiple concurrent event loops. Libuv uv_req_t structs are also exposed to lua this time around. They work mostly the same as the handle structs. I ref them upon creation and unref them when the callback fires. And yes, I'll need to unref first-thing in the callback in case of early exit due to error states. The other big difference in this new version is how lua_States are allocated. All events emitted (like connection, timeout) will call the lua callback in a new coroutine that inherits shared scope from it's parent lua_State. One-off functions like uv.close and uv.write will suspend the current coroutine and resume when the operation is done. This makes things much simpler in some respects and makes the lua code much more linear. The node.js style APIs in luvit will probably stay callback based for API consistency, but I hope people will migrate to the more minimal API in luv and use the upcoming luvi project to build their own luvit style platforms. On Mon, Sep 29, 2014 at 11:57 PM, Martin Croome <[email protected]> wrote: > This definitely helps: > > #define FS_CALL(func, cb_index, path, ...) > \ > do { > \ > uv_err_t err; > \ > int argc; > \ > if (lua_isfunction(L, cb_index)) { > \ > if (uv_fs_##func(luv_get_loop(L), req, __VA_ARGS__, luv_after_fs)) { > \ > err = uv_last_error(luv_get_loop(L)); > \ > luv_push_async_error(L, err, #func, path); > \ > uv_fs_req_cleanup(req); > \ > > * free(req->data); > \* > > * return lua_error(L); > \* > } > \ > return 0; > \ > } > \ > if (uv_fs_##func(luv_get_loop(L), req, __VA_ARGS__, NULL) < 0) { > \ > err = uv_last_error(luv_get_loop(L)); > \ > luv_push_async_error(L, err, #func, path); > \ > uv_fs_req_cleanup(req); > \ > > * free(req->data); > \* > > * return lua_error(L); > \* > } > \ > argc = luv_process_fs_result(L, req); \ > lua_remove(L, -argc - 1); > \ > > * uv_fs_req_cleanup(req); > \* > > * free(req->data); > \* > return argc; > \ > } while (0) > > > -- > You received this message because you are subscribed to the Google Groups > "luvit" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "luvit" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
