Date: Fri, 21 Nov 1997 15:57:29 -0700 (MST) From: Charles Mott <cmott@srv.net> To: Curtis Bray <cbray@best.com> Cc: freebsd-hackers@freebsd.org Subject: Re: malloc() problems in children after using rfork() Message-ID: <Pine.BSF.3.96.971121154744.3847B-100000@darkstar.home> In-Reply-To: <Pine.BSF.3.96.971121133610.10841A-100000@shell5.ba.best.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 21 Nov 1997, 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 > I've been dealing a little with the same problem, and I decided to use regular forking and then to use mmap() to have a shared memory area between processes. I know threading is supposed to be great and all, but what I see is alot of minor dfferences between operating systems that make it difficult to be really portable. Often thread-safe libraries are missing on target systems or have slightly different function names (like Solaris). rfork() looks like an interesting function, but it doesn't seen widespread in Unix yet (I just checked for it on linux and OSF). I seem to remember Linus making a a big deal about a clone() call. Charles Mott
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.971121154744.3847B-100000>