Date: Thu, 30 Jan 1997 23:37:26 -0800 (PST) From: Julian Elischer <julian@current1.whistle.com> To: Martin Cracauer <cracauer@wavehh.hanse.de> Cc: Terry Lambert <terry@lambert.org>, rminnich@Sarnoff.COM, freebsd-hackers@freebsd.org Subject: Re: Using rfork() / threads Message-ID: <Pine.BSF.3.95.970130233116.15337B-100000@current1.whistle.com> In-Reply-To: <9701310238.AA28758@wavehh.hanse.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 31 Jan 1997, Martin Cracauer wrote: > > > > > >VM space handling is a little different. If you request VM space sharing, > > > >you don't exactly get Vm address space sharing: what you get is instead > > > >shared data areas where in normal fork they are copied. More details on > > > >request. The effect is what you want, though: shared data areas. > > > > > > Could you explain a bit more. What exactly is the difference between > > > VM space sharing and shared data areas from the process' and the > > > kernel perspective? > > > > The per process open file table points to the same location, for one > > (that's actually a biggie). If I open a file in one process, it is > > open for both processes. If I close it, it's closed. There is one > > fd offset associated with the object -- if one process writes it, > > the offset is advanced, and if the other writes it, it's advanced > > again. There is a potential race as to who gets to do the write. > > Sure, so much is clear. > > But the original comment quoted topmost sounded like there are two > sperate concepts called "VM address speace sharing" and "shared data > areas", which is the same thing for me. Maybe one the these terms > implies that one of them has resources like the descriptor table on > board and the other not, but then I never heard of this term usage. There is VM space sharing, and then there is what rfork CURRENTLY does, which is VM object sharing.. in teh first one, the 'vmspace' structure normally associated with a process simply has it's reference cont incremented.. in the second, each object in teh space has it's reference count incremented.. The differnece is that in teh first, any NEW REGIONS mapped by one process are seen by the other where in the second, only regions that already existed at teh time of the rfork() are shared and new regions are private.. the reason that (1) is not yet implimented is that the kernel stack is in that VM at the same address for each process, and this MUST be unique per process.. The SMP code must have solved this some how, so if they finally check in that code we should be able to switch to (1). > > Hence my question. > > Martin > -- > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > Martin Cracauer <cracauer@wavehh.hanse.de> > http://cracauer.cons.org > Fax +49 40 522 85 36 >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.95.970130233116.15337B-100000>