From mboxrd@z Thu Jan 1 00:00:00 1970 From: "William K. Josephson" To: 9fans@cse.psu.edu Subject: Re: [9fans] Re: Cross-platform Message-ID: <20010102165216.A22201@honk.eecs.harvard.edu> References: <20010101191404.A4360199E7@mail.cse.psu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: ; from randolph@panix.com on Tue, Jan 02, 2001 at 05:51:09PM +0000 Date: Tue, 2 Jan 2001 16:52:16 -0500 Topicbox-Message-UUID: 418ab32c-eac9-11e9-9e20-41e7f4b1d025 On Tue, Jan 02, 2001 at 05:51:09PM +0000, Randolph Fritz wrote: > On Mon, 1 Jan 2001 19:33:05 GMT, Russ Cox wrote: > > > >the scripts that do everything require > >byron rakitzis's rc and the inferno mk, > >but it'd be nice to do without them. > >rfork(RFMEM) is the sticking point, if i > >remember correctly. > > > > Newer (2.2/libc2) Linux kernels support an __clone() system call, > which could be used, so far as I can tell, to implement most of > rfork(). Of course, one would also have to port any necessary > synchronization primitives. Yes. You can't get all of the rfork() semantics with __clone(2), of course, but as I said, I've already implemented what you can get -- it is a straightforward hack. The trouble is that the interface is a kludge compared to fork as you'll need to futz with some inline assembly to set up the stacks. Although to a lesser extent, the same is true of FreeBSD rfork(RFMEM) as, contrary to the manual page, rfork fails to split the stack. More annoying still, you have to do it for each different Unix. The documentation for kernel threads for DU aka OSF/1 was virtually non-existant on a number of sites I use, for instance. -WJ