Date: Sun, 21 Mar 1999 23:48:04 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: Brian Feldman <green@unixhelp.org> 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: <199903220748.XAA16584@apollo.backplane.com> References: <Pine.BSF.4.05.9903212004580.3722-100000@zone.syracuse.net>
next in thread | previous in thread | raw e-mail | index | archive | help
:> :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!
:> : 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199903220748.XAA16584>