Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Message-ID: <A5374D237E78D41195810090279CC91A05602D3F@xcup04.cup.hp.com>
From: "MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1)"
 <madhusudan_mathihalli@hp.com>
To: dev@httpd.apache.org, "'dev@apr.apache.org'" <dev@apr.apache.org>
Subject: RE: [PATCH] shmem.c - again
Date: Thu, 13 Sep 2001 19:58:48 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"

Hi,
	I was wondering if anybody got a chance to look at the patch. If
this looks okay, I was thinking of sending out a patch for the SSL Session
Caching using SHMHT & SHMCB.
	Any feedback / suggestion is welcome.

Thanks
-Madhu

-----Original Message-----
From: MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1)
[mailto:madhusudan_mathihalli@hp.com]
Sent: Wednesday, September 12, 2001 2:22 PM
To: dev@httpd.apache.org; 'dev@apr.apache.org'
Subject: [PATCH] shmem.c - again


Hi,
	I've modified the shmem.c to have a another shared memory segment
for storing the allocation details. I've also tried to ensure that all the
computation is based on offsets (stored in the shared memory again) - so
that if different processes map the shared memory at different addresses,
the memory mgmt should still work.
	As regards testing, I've done some minimal testing (testshmem,
shmcb, shmht) - but there may be lots of problems.. Also, the code may
require perf. tuning - I haven't yet looked into those aspects.. Pl. let me
know for any clarifications..
	'waiting for your feedback / suggestions..

Thanks
-Madhu


-----Original Message-----
From: Ryan Bloom [mailto:rbb@covalent.net]
Sent: Sunday, September 09, 2001 5:39 PM
To: dev@httpd.apache.org; MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1);
'dev@httpd.apache.org'
Subject: Re: FW: [PATCH] shmem.c


On Sunday 09 September 2001 17:23, MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1)
wrote:
> Hi Ian,
> Thanks for the suggestion.. I certainly like the first idea (infact, that
> was also one of the idea I'd proposed earlier). But, I'm not sure how
> *open* are others to create a seperate shared memory just for maintaining
> the allocation table..

The only problem is going to be ensuring that the platform has enough
shared memory to handle both segments.  I think we can just return an
error if we run out of shared memory though.  IOW, +1 for having a second
shared memory segment for the control data.

Ryan

>
> As regards your second idea, I'm not comfortable with it - it'd introduce
a
> lot of performance overhead - especially with IPC's around..
>
> Thanks for your suggestions..
> -Madhu
>
>
> -----Original Message-----
> From: Ian Holsman [mailto:ianh@cnet.com]
> Sent: Sunday, September 09, 2001 3:54 PM
> To: dev@httpd.apache.org
> Subject: Re: FW: [PATCH] shmem.c
>
>
> Hi Madhu.
> the only way I can think of handling this is to store the memory
> block list in another piece of shared memory/mmap (allocated seperatly)
>
> The other method I can think of is to spawn a seperate process which
> would hold all the memory list information, and it would do all the memory
> management
> and the other processes would communicate it via some IPC.
>
> the problem is that shared memory is NOT guarnteed to be in the same space
> for
> each process.
>
> ..Ian
>