Mailing-List: contact modperl-help@perl.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (asf.osuosl.org: local policy)
In-Reply-To: <200603181626.12293.mod_perl@whohasit.com>
References: <200603181626.12293.mod_perl@whohasit.com>
Mime-Version: 1.0 (Apple Message framework v746.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <4362F432-AC2E-4DC1-B552-1A62944923F3@2xlp.com>
Cc: modperl@perl.apache.org
Content-Transfer-Encoding: 7bit
From: Jonathan Vanasco <modperl-list@2xlp.com>
Subject: Re: Semaphores
Date: Sat, 18 Mar 2006 19:55:14 -0500
To: Bill Whillers <mod_perl@whohasit.com>


i asked something like that once before (though not in terms of  
mod_perl) , and was told this:

	if the disk doesn't have a lot of read/writes already, the the OS  
should optimize a bunch of the filechecking into memory and won't  
touch the disk
	if it does have a lot of use ( uploads/ shred use as email/imap/ 
etc ) then use either memcached or another in-memory system /  
daemon / socket connection that never  touches the disk

i know little of how the kernel handles that sort of stuff

the one thing i'd note about your plan is this:
	if you're updating a large hash, then on update that hash will be  
copied into each child -- it won't be shared among the apache  
children.  i'm not sure how the memory mapping works - will all of  
the hash be replaced with per-child memory, will only parts.  someone  
w/more knowledge of the internals would be better off answering  
that.  but the point is that  you end up losing a lot of shared  
memory space, which (i think) defeats the point of having a large  
hash of data in the first place.
	personally, i do a stop/start whenever i need to handle a data change