Unfortunately, none of our mmap-based datastructures are released. A common solution for us is to mmap a region of memory, and then lay out OCaml objects into that region, out of reach of the GC. We make sure through some type-level tricks that the OCaml objects don’t contain any ordinary pointers, only immediates, and we manage that memory manually. Once in that mode, either mutexes and the like, or just careful use of the x86-TSO model let you reason about what you have on the inside.
Well, yeah, you cannot compete with Erlang for exactly this use case, as the whole runtime and language is build around this target (async I/O and actors/messages). I’ve written a big system in Erlang and I can attribute. Erlang is an absolute beast in this regard. But things are rosy only when you can handle all the load with a single Erlang node (machine), problems start to pile up rapidly when you can’t. Of course, Erlang still remains one of the best for this kind of tasks (if not absolutely the best), but I no more enjoy writing it, after learning OCaml (no proper types). Distributed Erlang is a struggle to get right, maybe quite a lot easier than things like C++ (or even Python), but still a big struggle.
And also, there are plenty of “server” domains where OCaml wipes the floor with Erlang (eg what @Yaron_Minsky describes - when you need lots of sequential CPU power - you can’t do that with Erlang) .
People write network servers in python all the time. Doesn’t Python have same multicore problems as OCaml it never stopped any one from writing networking server in it. ssh(paramiko) smtp and http server (gunicorn) are few examples.
PS: I know paramiko is not a server but an ssh library but if there is a mature library there are probably several programs running over it in production. (yeah that’s just a speculation).
Also as a side note, can’t we use multiple processes and fork join to do multicore processing