Date: Tue, 25 Nov 1997 15:42:09 -0800 From: Julian Elischer <julian@whistle.com> To: nash@mcs.com Cc: cbray@best.com, freebsd-hackers@freebsd.org Subject: Re: malloc() problems in children after using rfork() Message-ID: <347B6251.41C67EA6@whistle.com> References: <199711220154.TAA05968@zen.nash.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?347B6251.41C67EA6>