I wrote this in response to another question, but also to get these things out of my head and written down. I am also curious about other interesting similar or related tools.
Personally I don't have done a lot of multi process racket in a practical sense, but I have looked into the options in the past, because it was interesting to me and I thought I could mention them here, to make this a sort-of overview.
- Parallelism with Places describes places, there are also distributed places on the same page for multiple machines. [os-threads, multi-machine]
- loci is a library by @pmatos that is similar to places but overcomes memory locking issues that can be observed with high core counts. [os-processes]
- tcp client-server (This could make sense if you don't want to use one of the places variants)
- Syndicate (classic) "Syndicate is an actor language where all communication occurs through a tightly controlled shared memory, dubbed the dataspace. [...]" It seems that a new version of syndicate is in development, but it currently doesn't have a working documentation link, so I am linking to the classic version which seems more stable.
- Goblins: a transactional, distributed actor model environment "Goblins is a quasi-functional distributed object system, mostly following the actor model. Its design allows for object-capability security, allowing for safe distributed programming environments.¹ [...]"
In general I would say when you want true multi-process, you still have something easier than dealing with multiple machines, but you are already very close to multi-machine solutions and I think you should be thinking about, whether you truly only need one machine or also multiple machines.
While with one machine you don't have to worry about network latency and uptime and all that stuff, when you build something that can run on multiple machines you often can create it, in a way so that it also easily runs on one machine. The reverse is more difficult, when it is done as a secondary thought.
For example ZeroMQ allows you to do messaging between applications running on the same or different machines, or also communicate between applications written in different programming languages. Racket seems to have 3 different ZeroMQ Packages I haven't tested those, so I am not sure which works best.
I have some experience using redis (with other programming languages) and I liked it a lot! When your problem can be mapped to redis, I think you should really consider it, because I found it to be quite a lot of fun to use it. redis packages (but if you really only need to merge message streams it may be a bit much)
Overall I like the simplicity and flexibility I would get from just writing my own tcp server with racket, especially in regards to being able to add new message types when the need arises. ZeroMQ seems very valuable if you have to interact with a multitude of programming languages. Redis if your problem fits it and you can make use of its features and for example use it as a cache (but it can do a lot more).