Comment by hanez
12 days ago
I added a section to https://git.xw3.org/fun/fun/src/branch/main/docs/internals.m... that describes this more detailed. I copied from other documents some seconds ago and I am not sure if this all is 100% correct actually. I will check this and will update the file if I find some wrong parts...
Isolated state is the sensible choice for embedding; fighting a GIL from the host language is miserable. I guess those shared-memory primitives are the escape hatch for when message passing serialization gets too expensive? The documentation seems consistent, though I'd be curious if the per-VM garbage collectors need to stop-the-world to scan those shared regions.
• Yes: isolated state (one VM per embed) is usually the right default. It avoids global locks (e.g., a GIL), makes scheduling simpler, and keeps failure/lifetime boundaries crisp.
• Yes: shared‑memory primitives are the “escape hatch” for when copying/serialization is too expensive, but they should be very carefully constrained.
• GC: If you design shared regions to be untraced (no VM heap pointers inside), each VM’s GC can remain independent and never stop other VMs. If you allow GC’d objects to be shared across VMs, you either need a global safepoint (stop‑the‑world across participants) or a more complex concurrent/barriered scheme.
I added some more information about this to the internals document.
Thanks for the link. I will take a look at the internals. The trade-off between global locks and isolated states is usually the most critical decision for embeddable languages so I am curious to see how the implementation handles it.