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:[EMAIL PROTECTED]
Sent: Wednesday, September 12, 2001 2:22 PM
To: [email protected]; '[email protected]'
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:[EMAIL PROTECTED]
Sent: Sunday, September 09, 2001 5:39 PM
To: [email protected]; MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1);
'[email protected]'
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:[EMAIL PROTECTED]
> Sent: Sunday, September 09, 2001 3:54 PM
> To: [email protected]
> 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
>

Reply via email to