linda_perf.lua crashes with Lua < 5.4. I suspect it is an interaction with the behavior of the garbage collector. My hypothesis is that the linda operation from the current test run can trigger GC, causing the collection of another linda from a previous run, that happens to be relying on the same keeper state. During collection, the second linda attempts to acquire access to the keeper state for cleanup, which can cause a deadlock because the first linda still has access. This doesn't happen with C-implementation, because the keepers use a recursive mutex.
If the hypothesis is true, adding more keeper states to Lanes configuration and assigning each new linda to a separate keeper should "fix" the deadlock.
potential fix: suspend gc during linda operation.
linda_perf.lua crashes with Lua < 5.4. I suspect it is an interaction with the behavior of the garbage collector. My hypothesis is that the linda operation from the current test run can trigger GC, causing the collection of another linda from a previous run, that happens to be relying on the same keeper state. During collection, the second linda attempts to acquire access to the keeper state for cleanup, which can cause a deadlock because the first linda still has access. This doesn't happen with C-implementation, because the keepers use a recursive mutex. If the hypothesis is true, adding more keeper states to Lanes configuration and assigning each new linda to a separate keeper should "fix" the deadlock. potential fix: suspend gc during linda operation.