:> :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
<dil...@backplane.com>
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
