Re: Reentrant GC

[Pierre Chapuis <catwell@...>]

On Wed, Nov 28, 2018, at 22:22, Tim Hill wrote:

> Which is exactly what we did on our project .. each Lua VM was event 
> driven from an event queue and each event call was monitored for time 
> via debug hooks and memory usage via a custom allocator. We then built a 
> dispatcher using an OS thread pool to drive the VMs. The fact that we 
> could do all that without a single patch to the Lua source was a 
> testament to its clean design.

Almost the same here. Sadly we cannot open source it.

>>From the point of view the user, it works a bit like Unix:
they can spawn Lua "processes" that run in separate Lua
threads, can respond to events and communicate through
some kind of "IPC".

>>From the point of view of the implementer, the execution
interface is abstract, so you can run the processes on top of
an OS thread pool, in an event loop, etc.

>>From a debug console we can do things like this:

    > ps
      PID          STATE REF         MEM     MAX_MEM          TIME NAME
        1        RUNNING   2    515.8KiB    636.3KiB       166.7ms init
    > spawn diagnose
    PID=9
    > ps
      PID          STATE REF         MEM     MAX_MEM          TIME NAME
        1        RUNNING   2    530.6KiB    636.3KiB       209.8ms init
        9           IDLE   1    723.5KiB    748.7KiB        10.0us diagnose
    > kill 9
    > ps
      PID          STATE REF         MEM     MAX_MEM          TIME NAME
        1        RUNNING   2    544.3KiB    636.3KiB       214.8ms init

The entire library is a mere 3000 lines of C and 500 lines of Lua,
and it runs on Mac, Linux, Windows, Android and iOS.

I wonder how many companies have re-built basically this,
with all the same tricks to interact with C code, event loops...

-- 
Pierre Chapuis