Date: Fri, 21 Nov 1997 16:16:32 -0800 From: Julian Elischer <julian@whistle.com> To: Curtis Bray <cbray@best.com> Cc: Alex Nash <nash@Mcs.Net>, freebsd-hackers@FreeBSD.ORG Subject: Re: malloc() problems in children after using rfork() Message-ID: <34762460.3F54BC7E@whistle.com> References: <Pine.BSF.3.96.971121133610.10841A-100000@shell5.ba.best.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?34762460.3F54BC7E>