From: ara.t.howard@...
Date: 2007-02-04T16:46:56+09:00
Subject: Re: Using fork to conserve memory

On Sun, 4 Feb 2007 khaines@enigo.com wrote:

> On Sun, 4 Feb 2007, Daniel DeLorme wrote:
>
>> I was talking about processes, not threads. The point is to use the 
>> copy-on-write capabilities of the OS to share the footprint of all the code 
>> that is loaded upfront while maintaining the independance of each process. 
>> i.e. http://en.wikipedia.org/wiki/Copy-on-write
>
> I experimented with this idea a little bit, with Mongrel, just doing some
> proof of concept type work, some months ago.  One should be able to alter
> the Rails handler to fork a process to handle a request.  However, there are
> a couple caveats.
>
> First, forking is not particularly fast.
>
> Second, and more importantly, it presents difficulties when dealing with
> database connections.  The processes will share the same database handle.
> That presents opportunities for simultaneous use of that handle in two
> separate queries to possibly step on eachother, and it also means that if
> one process closes that database handle (such as when it exits), that will
> affect the other's database handle, as well.
>
> Neither is necessarily a showstopper, and there are ways or working around
> the db handle issues, so it may be worth some real experimentation.

and you've just touched the tip of the iceberg: file locks are inherited, as
are stdio buffers, which can get flushed twice.

i wonder if people realize the size of a process is reported in virtual memory
and not in actual memory usage?  in the case of something like rails tons of
the memory will be shared in the page cache.

cheers.

-a
-- 
we can deny everything, except that we have the possibility of being better.
simply reflect on that.
- the dalai lama