From dev-return-4255-apmail-apr-dev-archive=apr.apache.org@apr.apache.org Sun Sep 09 08:13:03 2001 Return-Path: Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 89534 invoked by uid 500); 9 Sep 2001 08:13:03 -0000 Mailing-List: contact dev-help@apr.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Delivered-To: mailing list dev@apr.apache.org Received: (qmail 89523 invoked from network); 9 Sep 2001 08:13:03 -0000 Message-ID: From: "MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1)" To: "'dev@apr.apache.org'" Subject: RE: [PATCH] shmem.c Date: Sun, 9 Sep 2001 01:12:44 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N 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: dev@apr.apache.org 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