Not having exceptions would indeed solve problems with exceptions. :slightly_smiling_face:

Racket’s places are based on Erlang’s share-nothing model of parallelism. Places are a incomplete solution, though, because they are too coarse-grained to substitute for an Erlang process. Some elaboration/extension of places to support more fine-grained tasks would get closer to Erlang, and the places implementation in Racket-on-Chez would be a lot closer to the right thing than the traditional Racket implementation, but it would require a concerted engineering effort to close the gap.

So the RacketCS places implementation is better than the one for vanilla Racket?

Since it wasn’t mentioned by name, the system that Erlang (and Elixir) uses is called the Actor Model. That’s what you’d want to look into if you want to understand the ideas there.

The Racket CS implementation of places is simpler and more flexible since, under the hood, places can share GCable values. A drawback is that all places share a single GC; probably the way forward is to make the GC itself run in parallel and not try to avoid the cross-place synchronization required to perform a GC.

That’s interesting. As you know I am interested in working on a parallel GC for Chez. I will take a look at places for Chez and investigate. Won’t the fact that places share a GC in Chez mean even more waiting on locked regions during GC between places which might mean places won’t scale to hundreds of them in a machine?

@pocmatos It’s not clear that this strategy can scale to 100s. But I’m going mainly on the GHC experience, which is apparently that a single GC space with stop-the-world collection can scale as long as the GC itself scales.

@mflatt that’s also how gc works and scales in Java, for what it’s worth