Details

Description

Kernel::fork() will probably have to use forkall() on Solaris to have the same semantics as on Linux and MacOS where all threads are copied.

According to http://docs.sun.com/app/docs/doc/816-5137/6mba5vpjq?a=view), Solaris' fork() creates a new process with only one thread (the caller thread). This has the bad side-effect of potentially leaving locks that were held by other threads still held, and may cause deadlock if any attempt is made to acquire those locks.

It should be noted that Kernel::fork is defined to clone only the calling thread, so simply using forkall() would result in an incompatibility with Ruby semantics.

I'm not sure what the best answer is; in both cases some code is going to break – code working with external resources is likely to break in the forkall() case (e.g. clones of the same thread in multiple processes writing to the same file), and code holding locks is likely to deadlock as described in the fork() case.

MenTaLguY MenTaLguY
added a comment - 31/Dec/07 2:42 PM It should be noted that Kernel::fork is defined to clone only the calling thread, so simply using forkall() would result in an incompatibility with Ruby semantics.
I'm not sure what the best answer is; in both cases some code is going to break – code working with external resources is likely to break in the forkall() case (e.g. clones of the same thread in multiple processes writing to the same file), and code holding locks is likely to deadlock as described in the fork() case.

Not a bug; Ruby's fork only forks one thread in all cases, which is the standard behavior of fork on most platforms. forkall would be nice to have, but it can be bound through FFI if anyone really needs it.

Charles Oliver Nutter
added a comment - 08/Feb/09 5:14 PM Not a bug; Ruby's fork only forks one thread in all cases, which is the standard behavior of fork on most platforms. forkall would be nice to have, but it can be bound through FFI if anyone really needs it.