Hi Tim Thanks for the confirmation. I'm still seeing some weird things happening with current Luvit when I run on an embedded ARM platform (may be build environment/kernel version/uclibc related but I'm still tracking it down. One of the issues is getting hung in epoll on exit.). Still trying to figure out some of them. I'm working on quite a large project which I'm basing on Luvit so I would *really* like to understand your timeline on a new luv version so that I do not waste time plugging leaks that will get fixed anyway. I'm about a month or two out from having to make a release. If you need any beta testing I'm open to it ...
A large portion of the project is planned to be open sourced. Currently added bits include ... linux native serial bindings ... web sockets plugin for Utopia ... mini-express-like app plugin for Utopia ... plus large portions of the final project which is under wraps for the moment and a few other bits and pieces. All the best Martin On Tuesday, September 30, 2014 4:51:19 PM UTC+2, Tim Caswell wrote: > > 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] > <javascript:>> 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] <javascript:>. >> 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.
