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
> <dil...@backplane.com>
>
>
> To Unsubscribe: send mail to majord...@freebsd.org
> with "unsubscribe freebsd-current" in the body of the message
>
Brian Feldman _ __ ___ ___ ___
gr...@unixhelp.org _ __ ___ | _ ) __| \
http://www.freebsd.org/ _ __ ___ ____ | _ \__ \ |) |
FreeBSD: The Power to Serve! _ __ ___ ____ _____ |___/___/___/
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
