From owner-freebsd-hackers  Tue Nov 25 15:56:00 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id PAA18461
          for hackers-outgoing; Tue, 25 Nov 1997 15:56:00 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA18449
          for <freebsd-hackers@freebsd.org>; Tue, 25 Nov 1997 15:55:57 -0800 (PST)
          (envelope-from julian@whistle.com)
Received: (from daemon@localhost)
	by alpo.whistle.com (8.8.5/8.8.5) id PAA23788;
	Tue, 25 Nov 1997 15:44:25 -0800 (PST)
Received: from UNKNOWN(), claiming to be "current1.whistle.com"
 via SMTP by alpo.whistle.com, id smtpd023779; Tue Nov 25 15:44:21 1997
Message-ID: <347B6251.41C67EA6@whistle.com>
Date: Tue, 25 Nov 1997 15:42:09 -0800
From: Julian Elischer <julian@whistle.com>
Organization: Whistle Communications
X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2-CURRENT i386)
MIME-Version: 1.0
To: nash@mcs.com
CC: cbray@best.com, freebsd-hackers@freebsd.org
Subject: Re: malloc() problems in children after using rfork()
References: <199711220154.TAA05968@zen.nash.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

nash@mcs.net wrote:
> 
> On 21 Nov, Julian Elischer wrote:
> >> The only locking malloc() performs is pthread_mutex_lock/unlock in the
> >> libc_r version.  The non-threaded version provides no locking at all.
> [...]
> > I just saw the other email
> >
> > he's using 2.2.5
> > rfmem don't work in 2.2.x.
> > well it DOES but it only shares EXISTING memory.
> > new allocations are not shared..
> 
> and in a subsequent email...
> 
> > New allocations from the kernel (done after the rfork)
> > are not shared..
> > this was fixed in -current but I'm pretty sure john has not back-ported
> > it.
> 
> Unless I'm missing something, even if the fix was brought into -stable
> it still won't allow multiple rforked(RFMEM|RFPROC) processes to malloc
> out of a shared data segment (without locking, of course).
> 
> Alex

of course you are right, and I'm not sure of the locking state of
malloc.

I do belive SOME work was done on it but I don't
know if it was completed.