From owner-freebsd-current Sun Mar 21 23:49:39 1999 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id BCE17150D3; Sun, 21 Mar 1999 23:49:38 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id XAA16584; Sun, 21 Mar 1999 23:48:04 -0800 (PST) (envelope-from dillon) Date: Sun, 21 Mar 1999 23:48:04 -0800 (PST) From: Matthew Dillon Message-Id: <199903220748.XAA16584@apollo.backplane.com> To: Brian Feldman Cc: Alfred Perlstein , "John S. Dyson" , samit@usa.ltindia.com, commiters@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Subject: Re: rfork() References: Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> :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 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message