Hacker News new | comments | show | ask | jobs | submit login

Forking creates a new process, initially "sharing" memory via copy-on-write semantics (and therefore being eligible to run on another core). However, C Ruby's default mark-sweep garbage collector touches pretty much all memory immediately, eliminating the typical memory savings of a forking model.

As I commented earlier, Ruby Enterprise Edition (made by the same guys as Passenger) ships an alternate GC that doesn't actually write to the memory space of the original objects in order to mark them.

As a result, some memory (but not necessarily as much as you'd expect) can be shared between processes forked from the same parent and running on multiple cores. Sort of a middle ground between totally separate processes and shared memory via non-GIL'ed threads.

So you won't get much by way of memory savings, but you might expand the volume of work each batch of threads (now on separate processors) could complete if you forked cores - 1 times?

There are different kinds of memory in a process, e.g. code segment, read-only data segment, and read-write data segment. The code and read-only memory can be shared between the parent and child processes. The read-write memory pages are copied-on-write when they are modified. There can be fair amount of sharing.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact