There is a possibility that it's a bug in luvit's C code. I'm currently busily integrating the new C backend into luvit.
In the new updated libuv backend, uv_fs_readdir was removed and a new uv_fs_scandir was added. In luvit I recently (earlier today) wrapped this into two functions. The first is fs.readdir(path, callback) that returns a list of file names. I also added fs.scandir(path, callback) that returns an iterator for each file. Here is the unit test in my feature branch to show the usage with callbacks, coroutines, or blocking sync code. https://github.com/luvit/luvit/blob/c274290954c5b23eccdac3fcabaf575dc2f2c633/tests/test-fs.lua#L109-L134 If you want, you can file an issue against luvit to fix the bug in the legacy code. It's still going to be a little bit till the new luvit 2.0 is ready to be released. If you want to test the new C bindings, clone the luvi-up branch of luvit and follow the instructions for setting up a dev environment. It doesn't require a C compiler thanks to the luvi project and prebuilt binaries. https://github.com/luvit/luvit/tree/luvi-up On Tue, Nov 4, 2014 at 3:06 PM, Eike Decker <[email protected]> wrote: > Hello, > > I have three directories that contain 9508 files in total. I am running > luvit 0.10.0-38-gca69dfa on a vagrant vm that's run inside a win8 host. > > When I try to read all directories in parallel (so scanning each directory > of those 3 through an async function), Luvit terminates with a segmentation > fault error message. > From what I observe, it successfully read the first (and smallest) > directory's list and passed it to my closure which completed its job as it > should. It won't call any other closure (that was spawned inside my > original coroutine). > Taking that observation I could identify that it looks like as if the > coroutine I created was garbage collected: > > -- crashing script: > ... (code) > coroutine.wrap(updateSnapshots)() > --- end > > -- not crashing script: > ... (code) > blah = coroutine.wrap(updateSnapshots) > blah() > --- end > > Further testing revealed: > > -- crashing script as well: > ... (code) > local blah = coroutine.wrap(updateSnapshots) > blah() > --- end > > So my main script terminates and *I assume* that the garbage collector > identifies the coroutine stored in the local variable as unused and removes > it, destroying all memory associated with it. When the second directory > callback is attempting to call the closure, it will naturally fail. > > ... > > I succeeded now to create a simple test case: > --- > function test() > require "fs".readdir("dir_with_4kfiles",function(err,dir) > collectgarbage "collect" > end) > require "fs".readdir("other_dir_with_5kfiles",function(err,dir) > collectgarbage "collect" > end) > end > > coroutine.wrap(test)() > --- > > Without the garbage collection the script terminates all right. Storing > the coroutine in a global variable makes the script work as well. If the > directories are sufficiently small, it won't crash either. Maybe because > the closure to be called is already scheduled or something... (I worked > less than 2 hours with luvit in total, so I don't really know anything ;)) > > I think I did as much as I could without diving into C code and a > debugger. I hope it helps to fix this issue. > > Cheers, > Eike > > -- > 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.
