Martin, I patched this leak here [1]. Does it look better to you?
[1] https://github.com/luvit/luvit/commit/20e226a57f05b20ae4c16c796fe3e3081bdfbe36 On 9/30/14, 4:37 PM, Martin Croome wrote: > It is already all done on top of Luvit (and running very nicely for > the most part) so it definitely needs to happen on top of that. I was > already thinking that I would split the whole luvit build process out > and build each element separately rather than your combined makefile > since I have had several issues with that any my toolchain which may > have some bearing on the issues I'm seeing (no certainty though. > switching on a lot of debugging has thrown up other issues as always > with smaller embedded systems). > > I saw that you had a separate makefile to build a shared library for > luv in your 1.0 project but some elements are still missing (fs.c for > example). I guess that will be what you finish off in the next week. I > can try to integrate that next week with Luvit once you have finished. > > I'm working within a very specific build system so it won't be very > relevant for wider consumption. > > On Tuesday, September 30, 2014 11:05:57 PM UTC+2, Tim Caswell wrote: > > I'm working full-time on the luv update. I expect it to be done > within a week. I'm not sure how much time will be needed to > migrate luvit to it though. Do you want to build on top of the > luvit APIs or are you willing to build on top of luv's APIs > directly? Also the general idea for luv's API is still under > discussion. You can see part of it > at https://github.com/luvit/luv/issues/65 > <https://github.com/luvit/luv/issues/65> > > On Tue, Sep 30, 2014 at 2:03 PM, Martin Croome > <[email protected] <javascript:>> wrote: > > 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 > <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 > <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] <javascript:>. > For more options, visit https://groups.google.com/d/optout > <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] > <mailto:[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.
