Luke Gorrie

> So what about all the projects caught in the middle, trying to support both Lua and LuaJIT? Löve2D would be an excellent example. I really hate the idea of...

Also relevant history: [Emacs/XEmacs schism](https://www.jwz.org/doc/lemacs.html). Emacs/XEmacs is worth considering as a cautionary tale for LuaJIT/RaptorJIT. Many years ago I spent/wasted a lot of energy on maintaining code that was "caught...

> Honestly Luke if you're so bothered about the C API, then just dump it. I am only trying to tease out all the trade-offs through discussion here. I don't...

Clarification: I am only *bothered* by people being caught in the middle between implementations. I want people to be able to warmly embrace their favourite implementation and take full advantage...

> Actually a large portion of Lua code is native, with people only reaching for the C API when they need speed. Trouble I have here is what @agladysh mentioned...

Thanks for the explanation @fogfx. I am reading `genlibbc.lua` for the first time. Does the value `~LJ_TNUMX+2` make sense even so? How come `+2` specifically? There is a comment: ```c...

@fsfod Generally I am wondering whether a custom calling convention can serve as an "80/20" solution for intrinsics. That is, to support most of the use cases for full-scale intrinsics...

... Sorry, there actually was a longer discussion over at the LuaJIT repo, which I will now reread... https://github.com/LuaJIT/LuaJIT/issues/100

I propose that we adopt the `core.worker` multiprocess model for spawning cooperating Snabb processes, provided that this will suit @petebristow. This framework did not exist when @petebristow was developing the...

I have belatedly pushed the API documentation for the `multiprocess-engine` branch ( #1021) here: https://github.com/snabbco/snabb/blob/82f335573a743fd608baa5ee966d3c5ef35183ab/src/README.md#multiprocess-operation-coreworker. @petebristow How does that API look to you?