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
MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1) wrote:
> Just forwarding it to the httpd mailing list - to get more inputs. [sorry if
> duplicate]
>
> Thanks
> -Madhu
>
> -----Original Message-----
> From: MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1)
> [mailto:[EMAIL PROTECTED]]
> Sent: Sunday, September 09, 2001 1:13 AM
> To: '[EMAIL PROTECTED]'
> Subject: RE: [PATCH] shmem.c
>
>
> Sorry for the delay in replying.. But, I'm wondering if it's at all possible
> to do any meaningful memory management without storing the characteristics
> of the memory chunk / block allocated.. By "meaningful memory mgmt", I mean
> a facility where freed memory blocks are tracked, and reallocated based on
> the need/requirement.
>
> I might be missing something here - but it'd be great if somebody would give
> me one possible way of doing such a thing.. I'd be happy to implement it..
>
> Pl. note that I'm not trying to question somebody's authority here, but
> because of my *limited apache knowledge*, I'm trying to get a better
> understanding of memory mgmt in apache.
>
> Thanks
> -Madhu
>
>
>
>
> -----Original Message-----
> From: Justin Erenkrantz
> To: [EMAIL PROTECTED]
> Sent: 9/8/01 12:59 AM
> Subject: Re: [PATCH] shmem.c
>
> On Fri, Sep 07, 2001 at 11:49:15PM -0700, MATHIHALLI,MADHUSUDAN
> (HP-Cupertino,ex1) wrote:
>
>>As regards the shmem_t, you're right.. I'm working on having it as a
>>
> part of
>
>>the shared memory itself - but I'm not sure if such a thing is
>>
> acceptable..
>
>>I was thinking of the following 2 alternatives (1) store the shmem_t
>>structure in the shared memory (either a different one or in the same
>>
> shared
>
>>memory segment) OR (2) store the memchunk characteristics along with
>>
> the
>
>>memory chunk - similar to MM.
>>
>
> -1 (veto) if it means that we can't do:
>
> - Create 1024KB shared memory segment
> - Allocate 256KB from that segment
> - (Repeat above three more times)
>
> This was the problem inherent with MM and which is why it was removed.
>
> The problem is that you can't often allocate more than what the user
> asked for because of hard system limits. (Therefore, you can't create
> a segment size of 1030KB when they ask for 1024KB because the system
> has a upper bound of 1024KB...). -- justin
>