From owner-freebsd-hackers Mon Jul 8 06:07:51 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id GAA02590 for hackers-outgoing; Mon, 8 Jul 1996 06:07:51 -0700 (PDT) Received: from terra.Sarnoff.COM (terra.sarnoff.com [130.33.11.203]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id GAA02581 for ; Mon, 8 Jul 1996 06:07:44 -0700 (PDT) Received: (from rminnich@localhost) by terra.Sarnoff.COM (8.6.12/8.6.12) id JAA18986; Mon, 8 Jul 1996 09:07:13 -0400 Date: Mon, 8 Jul 1996 09:07:12 -0400 (EDT) From: "Ron G. Minnich" X-Sender: rminnich@terra To: hackers@freebsd.org Subject: Re: filemalloc etc. for shared memory between processes In-Reply-To: <199607080000.UAA24967@kropotkin.gnu.ai.mit.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > What about using one mmap'd region, then dividing it up malloc-style > (see Knuth) instead of constanly mmapping lots of possibly tiny files? > It may be good to look at mmalloc (distributed with gdb) for using > malloc with mmap. Another advantage of this is that the regions > filemalloc()'d can hold pointers as offsets to the start of the mapped > region that would hold valid for all processes. I'll try to find this, I did this also but it was a few years back. I hacked gnu malloc to use a mapped file. BUT: the filemalloc I posted was explicitly for SHARED MEMORY, and that is why the sizes etc. were fixed: not easily changed right now after you fork. Doable, much harder. ron