Comment by storystarling
17 days ago
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.