Date: Sun, 21 Mar 1999 08:56:34 -0600 From: "Richard Seaman, Jr." <dick@tar.com> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: Brian Feldman <green@unixhelp.org>, Alfred Perlstein <bright@rush.net>, "John S. Dyson" <dyson@iquest.net>, samit@usa.ltindia.com, commiters@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Subject: Re: rfork() Message-ID: <19990321085634.F32029@tar.com> In-Reply-To: <199903210743.XAA09505@apollo.backplane.com>; from Matthew Dillon on Sat, Mar 20, 1999 at 11:43:14PM -0800 References: <Pine.BSF.4.05.9903210528300.97734-100000@zone.syracuse.net> <199903210743.XAA09505@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Mar 20, 1999 at 11:43:14PM -0800, Matthew Dillon wrote: > :For the suggest something, you realize that with Richard's VM_STACK code it > :should be relatively trivial to make this automatic (suggestion: add > :RFSTACK flag). > : > : Brian Feldman _ __ ___ ___ ___ > : green@unixhelp.org _ __ ___ | _ ) __| \ > : http://www.freebsd.org/ _ __ ___ ____ | _ \__ \ |) | > : FreeBSD: The Power to Serve! _ __ ___ ____ _____ |___/___/___/ > > If the goal is to completely share the address space, which > RFMEM does, you can't split anything, not even the stack. It > sure would be useful if there were a standard clib call adequate > for calling rfork() and calling a function in the child w/ a new > stack. Possibilities for the clib call are noted in separate messages. The problem with adding an "RFSTACK" flag to the rfork call is that a lot of the time the caller of rfork wants to control the stack address. If you just add an "RFSTACK" flag, the system will have to pick the address. The linux clone syscall (different from the linux clone libc function) takes two additional parameters that rfork doesn't. One of those parameters is the stack TOS address, and the other is the exit signal the clone'd process should return (so "kthreads" can return different exist signals from child processes). As long as rfork doesn't take a TOS parameter as input, you will have to use an assembly language wrapper to rfork to graft the stack onto the child process. The primary reason I've seen, that the caller of rfork wants to control the TOS address, is so there is an efficient thread_self function. By marrying TLS to the stack, and using aligned/uniformly spaced stack addresses, thread_self can examine its stack, and derive the address of the TLS efficiently. Now, it would be very nice to find a better way to do the thread_self stuff. -- Richard Seaman, Jr. email: dick@tar.com 5182 N. Maple Lane phone: 414-367-5450 Chenequa WI 53058 fax: 414-367-5852 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19990321085634.F32029>