ara.t.howard wrote:
> 
> On Oct 18, 2007, at 9:32 AM, Yohanes Santoso wrote:
> 
>> I don't favour the long-running process model for server. I prefer to
>> fork() for each request. So I'm rarely bothered by whatever ruby's GC
>> quirknesses that I may have triggered. I understand that this approach
>> is not trendy anymore and RoR does not support this model, but I'm
>> just throwing it out in the open for an alternative work-around where
>> possible.
>>
> 
> that's quite interesting because, while i'm not the memory expert you 
> are, i've settled on exactly that model for the many many server process 
> i've written for 24x7 systems: the robustness simply cannot be beaten.
> 
> kind regards.
> 
> a @ http://codeforpeople.com/
> -- 
> share your knowledge.  it's a way to achieve immortality.
> h.h. the 14th dalai lama
> 
> 
> 
> 

fork() (or clone() in Linux) is cheap ... it's actually *instantiating* 
the thread or process that costs! Depending how smart your kernel is, 
you could be doing it one page fault at a time. And no matter *how* 
smart your kernel is, above a certain ratio of virtual process size over 
real process size, it's going to start thrashing. Pay me now or pay me 
later, etc.

That's what's so attractive about lightweight communicating processes -- 
emphasis on *lightweight*. It doesn't cost much to start them up, move 
them around, kill them, etc.