From owner-freebsd-hackers Fri Nov 21 13:45:09 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA16084 for hackers-outgoing; Fri, 21 Nov 1997 13:45:09 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from shell5.ba.best.com (cbray@shell5.ba.best.com [206.184.139.136]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA16067 for ; Fri, 21 Nov 1997 13:45:01 -0800 (PST) (envelope-from cbray@shell5.ba.best.com) Received: from localhost (cbray@localhost) by shell5.ba.best.com (8.8.7/8.7.3) with SMTP id NAA15206; Fri, 21 Nov 1997 13:44:55 -0800 (PST) Date: Fri, 21 Nov 1997 13:44:53 -0800 (PST) From: Curtis Bray To: Alex Nash cc: Curtis Bray , freebsd-hackers@freebsd.org Subject: Re: malloc() problems in children after using rfork() In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk 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