Date: Fri, 19 Sep 1997 02:12:33 +0200 (CEST) From: Mikael Karpberg <karpen@ocean.campus.luth.se> To: dyson@FreeBSD.ORG Cc: current@FreeBSD.ORG Subject: Re: FYI: regarding our rfork(2) Message-ID: <199709190012.CAA11932@ocean.campus.luth.se> In-Reply-To: <199709182235.RAA09701@dyson.iquest.net> from "John S. Dyson" at "Sep 18, 97 05:35:33 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
According to John S. Dyson: > I am going to be changing our rfork implementation in the following ways: > > Rename RFMEM to RFSHMEM, implying that we are fully sharing memory. > Also implying that we don't support RFMEM in the same way as other > OSes might. Add an additional argument to rfork(2) to support > specifying a new stack address in the child. This argument is > meaningful only if RFSHMEM is specified. This mod will eliminate > some potential timing windows when the child is running with the > parents stack. It will also eliminate the need for certain > "gymnastics" in code that uses rfork with RFSHMEM. > > I'll be committing the changes tonight, so let me know if anyone > has problems with the concept. Sounds good, but I as always I have some nosy questions out of personal interest only: Is rfork() in any way portable enough to even consider keeping it happy in porting software? Is it/should we try to keep it compatible with other BSDs at least? If so: Would be be hard to do a "real" RFMEM too? (Probably not instantly since it is wanted that things fall over from the lack of RFMEM if they are using it. But when they are fixed.) Will it be a problem for compilation if the new argument is not given, or will it be a "..." argument, or something? Thanks for listening... :-) /Mikael
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199709190012.CAA11932>