Date: Mon, 22 Mar 1999 12:23:12 +0000 (GMT) From: Brian Feldman <green@unixhelp.org> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: 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: <Pine.BSF.4.05.9903221221300.10137-100000@zone.syracuse.net> In-Reply-To: <199903220748.XAA16584@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 21 Mar 1999, Matthew Dillon wrote: > :> :proc B returns since proc B is going to immediately switch over to a new > :> :stack? > :> > :> The return address for the procedure call is on the stack. If something > :> munges the stack after the physical rfork occurs but before both processes > :> can return from the rfork() clib function, then one of the processes > :> attempting to return will pop a bogus return address and seg fault. > : > :What's to stop the RFSTACK from copying the stack itself into the new stack > :that is located elsewhere in RAM and attached to the vm space? Actually, > :rfork() would just set it in the trap frame anyway, so there would be no > :extra user code to do this. > > Why make rfork() a thousand times slower when performance is almost > certainly an issue for the people using it? Since the one of the big > points of using rfork() the way we are using it is to avoid copying > pagetables, descriptor tables, and so forth, we sure don't want to > add any back in! It wouldn't be appreciably slower. The only difference would be when one provides RFSTACK and extra arg stackaddr, which would simplify things for the coder greatly! This would allow the old method to still work, so what's the problem? If anything, it would save _human_ time. > > > :> : Brian Feldman _ __ ___ ___ ___ > :> > : Brian Feldman _ __ ___ ___ ___ > > -Matt > Matthew Dillon > <dillon@backplane.com> > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > Brian Feldman _ __ ___ ___ ___ green@unixhelp.org _ __ ___ | _ ) __| \ http://www.freebsd.org/ _ __ ___ ____ | _ \__ \ |) | FreeBSD: The Power to Serve! _ __ ___ ____ _____ |___/___/___/ 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?Pine.BSF.4.05.9903221221300.10137-100000>