From: "M. Edward (Ed) Borasky" Date: 2007-09-26T23:46:35+09:00 Subject: Re: Ruby Scales just fine ! Alex Young wrote: > James Edward Gray II wrote: >> On Sep 25, 2007, at 8:24 PM, Ari Brown wrote: >> >>> >>> On Sep 25, 2007, at 8:38 PM, Yukihiro Matsumoto wrote: >>> >>>> Hi, >>>> >>>> In message "Re: Ruby Scales just fine !" >>>> on Wed, 26 Sep 2007 09:28:36 +0900, Ari Brown >>>> writes: >>>> >>>> |Soo........ Ruby DOES use multiple cores? I read somewhere that it >>>> |didn't (probably this thread). >>>> >>>> Single Ruby process does not. But we can use as much cores we have by >>>> forking processes, and usually it's the case for web applications. >>> >>> So fork() moves to a new processor if there is one, else a new thread? >> >> fork() creates another process which your schedular is free to handle >> as it sees best. This may mean running that process on a different >> CPU, if the schedular decides that's the way to go. > OT, but is there a combination of libraries/OS/network-level > accoutrements that would allow a scheduler to migrate the process to > another host on fork()? > If you mean the "native" scheduler that's built in to the OS, you or someone would have to write a library extension in C to make that happen, which is OS dependent, and in the case of Linux, kernel version dependent as well. In general, however, unless you *really* *really* know what you're doing and *why* you're doing it, you're better off letting the OS scheduler do its things without even trying to give it *hints* on how to treat your code. It's not nice to fool the scheduler -- that way lies deadlocks, race conditions, starving philosophers, etc. Just throw hardware at it -- lots of cores, lots of RAM, lots of light-weight processes communicating by message passage and immutable objects a la Erlang. The next version of Event Machine will have the underlying mechanisms to make this work.