Date: Thu, 30 Jan 1997 20:37:34 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: Andrew.Gordon@net-tel.co.uk Cc: rminnich@Sarnoff.COM, freebsd-hackers@FreeBSD.org Subject: Re: Re(2): Using rfork() / threads Message-ID: <199701310337.UAA01418@phaeton.artisoft.com> In-Reply-To: <"40b1-970131030103-8AD9*/G=Andrew/S=Gordon/O=NET-TEL Computer from "Andrew.Gordon@net-tel.co.uk" at Jan 31, 97 03:01:17 am
next in thread | raw e-mail | index | archive | help
> > 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. > > What synchronization primitives are you supposed to use between two > rfork()ed processes? Using SysV sepmaphores seems a bit perverse > (and would they even work in the environment after a rfork() ?), > but talking through pairs of sockets to lock small datastructures > seems a bit heavyweight. You use processor test-and-set (CMPTST) on a shared region. If you want SMP cache coherency for the same situation, you write a kernel module that uses IPI invalidation queueing. Time for a set of mutex libraries that are SMP aware? It would be easier in elf so you could constructorize the mutex initialization to decide whether or not to make kernel or non-kernel calls at load time. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199701310337.UAA01418>