3 ms·
How Loom manages killing a vthread from another vthread? In Erlang you can do it safely and without needing to check a cancellation signal in the process to be
by nahuel0x 6y ago
How Loom manages killing a vthread from another vthread? In Erlang you can do it safely and without needing to check a cancellation signal in the process to be killed. Also, Erlang has per-process heaps, an usually overlooked feature that gives soft-realtime capabilities, avoiding GC hiccups. JVM+Loom seems to be closer to Go than Erlang.
- aidenn0 6y agoDoes that mean message-passing in Erlang necessarily includes copying?
- toast0 6y agoI'm not qualified to say it copying is necessary at a language level, but in terms of implementation, BEAM always copies for message passing, AFAIK. A small caveat is that Erlang has a Refc binary type that is reference counted, when sending a message with a refc binary to another process on the same node the content isn't copied, just the reference value (like a pointer) and the reference count is incremented. There is an area where copies could potentially be avoided, but I don't think they are. Recent versions of beam have an optional off-heap message queue feature; some software patterns have a proxy process that accepts messages and sends them as-is to another process; if the message is off-heap for the proxy process, and it would send to the next process off-heap, it could be possible to avoid copying it, but it might be a bit tricky. (I don't think this is done, but that's why I said AFAIK earlier)
- thu2111 6y agoJVM has pauseless GCs now, in fact two of them! The Erlang multi-heap approach is much less compelling now GC pauses are finally vanquished as a problem.