From owner-freebsd-hackers Fri Nov 21 16:20:28 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA27057 for hackers-outgoing; Fri, 21 Nov 1997 16:20:28 -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 QAA27042 for ; Fri, 21 Nov 1997 16:20:24 -0800 (PST) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id QAA04927; Fri, 21 Nov 1997 16:18:42 -0800 (PST) Received: from UNKNOWN(), claiming to be "current1.whistle.com" via SMTP by alpo.whistle.com, id smtpd004918; Fri Nov 21 16:18:38 1997 Message-ID: <34762460.3F54BC7E@whistle.com> Date: Fri, 21 Nov 1997 16:16:32 -0800 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2-CURRENT i386) MIME-Version: 1.0 To: Curtis Bray CC: Alex Nash , freebsd-hackers@FreeBSD.ORG Subject: Re: malloc() problems in children after using rfork() References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Curtis Bray wrote: > > On Fri, 21 Nov 1997, Alex Nash wrote: > > > On Fri, 21 Nov 1997, Curtis Bray wrote: > > > > > Hi, > > > > > > I'm trying to use rfork(RFPROC | RFMEM) so that all the children can > > > share the same address space with their parent. > > > > > > If I have multiple children issuing mallocs the children seem to core > > > dump. Once I turn the RFMEM flag off I have no problem mallocing (but > > > of course I loose the shared address space). Anyone know what I could > > > be doing wrong here? Do I have to put semaphores around every malloc?? > > > I hope that's not the case... Thanks in advance! > > > > 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 was hoping to avoid the pthread package because I need my threads (or > children processes in this case) to perform a lot of file IO. I appears > that since non-blocking file IO doesn't exist in 4.4BSD that this approach > would cause all my threads to block while one of them is waiting for data > off the disk. Obviously this defeats the purpose of a threaded app! > > From what I'd seen in the mail list archives, it appears the rfork() > method may work better for these IO bound applications. I was assuming > that once the RFMEM flag was set, then the VM system would respect > multiple children sharing the same address space. That's what I've > gotten from the man pages anyway: > > man 2 rfork: > > RFMEM If set, the kernel will force sharing of the entire ad- > dress space. The child will then inherit all the shared > segments the parent process owns. Other segment types > will be unaffected. Subsequent forks by the parent will > then propagate the shared data and bss between children. > The stack segment is always split. May be set only with > RFPROC. > > Am I mistaken in this approach? > > Curtis you WOULD be correct, except that RFMEM is only partially implemented for 2.2.x 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.