Rewriting Jepsen to Lua language

Why Lua? There are a number of reasons of that.

The first and the main reason - Lua is embedded into Tarantool, in-memory data storage, on what I’m working on. All our functional tests written in Lua, other programming languages can be used too using so-called connectors, but it makes debugging and maintenance more complicated.

The second reason is a simplicity. Lua is simple, but not simplistic: Lua has a simple, yet powerful syntax which fits on a single page. The semantics are consistent and intuitive. Additionally, Lua has a seamless integration with C and C++ source code with LuaJIT’s FFI. It is a quite fast and simple mechanism allowing to call C functions directly. LuaJIT’s FFI is substantially faster than C - about 25% faster than a native C function call to a shared object function.

The third reason is a nice Lua functional library. One of Jepsen’s strength is a functional generators used for producing operations and nemeses. Clojure is a functional language and generators is in its nature. Lua is imperative programming language, but it has a functional library too. What Kyle Kingsbury says about Jepsen generators: “Realistic generator tests yield rates over 20,000 operations/sec, which seems more than sufficient for Jepsen’s purposes.”. 20k ops/sec is not so much for testing of real production systems. Generators in Lua functional module allows to build generators with exceptional performance, most of them produce about 0.8-1.4M ops per second.

The fourth reason is using cooperative multitasking instead of preemptive one. Cooperative multitasking is less error-prone than preemptive one. Jepsen library has problems with multithreading, that Kyle Kingsbury “have never had the chance to dig in and fix”. Using fibers and coroutines makes code simple and allows spending less time in debugging of multithreading.

Source code: