apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@covalent.net>
Subject Re: [PROPOSAL] apr_shm_t, a new shared memory API to replace old
Date Tue, 08 Jan 2002 07:07:18 GMT
From: "William A. Rowe, Jr." <wrowe@covalent.net>
Sent: Monday, January 07, 2002 7:00 PM


> From: "'Aaron Bannert'" <aaron@clove.org>
> Sent: Monday, January 07, 2002 6:49 PM
> 
> > On Mon, Jan 07, 2002 at 07:49:38PM -0500, MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1)
wrote:
> > > But, as regards SSL session caching, the cache initialization is done only
> > > in the 2nd phase, and all the children are supposed to inherit the
> > > segment-id from that point onwards.. (somebody, pl. correct me if i'm wrong)
> > 
> > The biggest thing that will be enabled with this API is the ability
> > for Win32 to join the game. This means that our API cannot normally
> > depend on inheritance (via fork()), which also means things get weird
> > for anonymous shared memory.
> 
> Correct.  Testing for APR_HAS_FORK, you can take a named shared memory
> path rather than anonymous for your cache.  I'll be implementing a patch
> for mod_auth_digest based on shm + rmm tonight, so this should be simple
> to follow.

FYI - these lines in mod_auth_digest;

/* Disable shmem until pools/init gets sorted out - remove next line when fixed */
#undef APR_HAS_SHARED_MEMORY
#define APR_HAS_SHARED_MEMORY 0

It's really not a showstopper to introduce Aaron's patch before .30 - especially
since he's been discovering bugs in the current implementation of shmem.

Only the scoreboard is affected at this instant, and the scoreboard will loose
it's malloc call (since the shm will return the block 'o bytes to use) and we
only had a single malloc call in the first place (not the place to be wasting
overhead on shmem.)

So we can deploy shmem changes very safely, before .30, and testing is trivial
(was insufficient in the first place :)

Bill


Mime
View raw message