The only overhead I see in theory is the additional process's kernel resources, which are negligible. Wherever you'd normally write to memory for some unsafe code to mutate, you instead write to the shared memory. Kernel is doing the same virtual mem protection either way, only in this case it opens up access to the child process too.
Am I missing something else, like shared mem being slower? Maybe the inability to share CPU caches?
The fact that you have a whole other process, was my line of thinking. If the scheduling doesn't play nice then latency will suffer. I don't really know in practice though.
Latency is an issue with file or network-based IPC, but shared memory is supposed to be the same speed as non-shared. Apparently the X window system relies on it a lot.
Scheduling, I dunno. Would imagine it's not bad as long as you don't spawn a ton of these.
Am I missing something else, like shared mem being slower? Maybe the inability to share CPU caches?