Re: Fengari: Why we rewrote Lua in JS

[Daurnimator <quae@...>]

On 27 July 2017 at 09:07, Hisham <h@hisham.hm> wrote:
> The linked article mentions that the approach of compiling Lua C code
> into the browser via Emscripten makes you end up with two garbage
> collectors. For this reason, simply building both a C library and its
> Lua/C binding with Emscripten and expecting them to work with Fengari
> doesn't sound feasible. But the approach I described above, in which
> the C library is compiled into JS and a Lua/JS binding is
> custom-written for it, does (unless I'm missing something—the Fengari
> authors will surely correct me if that's the case).

Actually it's feasible.

The core issue is that a garbage collector needs to be able to sweep
*all* references: when you e.g. compile lua via emscripten the JS GC
has no idea what lua objects reference what. However the lua C api
doesn't create out-of-band references: you create+manage lua
references yourself.

That doesn't mean that it's currently turn-key to get an
emscripten-compiled lua C library to work with fengari. Someone will
need to write a table of emscripten <-> fengari bridge functions (one
for each C-api function).

However, note that fengari doesn't support __gc (which most C bindings
use), and can't until JS supports finalisers.