From owner-freebsd-current Sun Mar 21 10: 6: 0 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 691B614D1E; Sun, 21 Mar 1999 10:05:59 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id KAA13805; Sun, 21 Mar 1999 10:05:38 -0800 (PST) (envelope-from dillon) Date: Sun, 21 Mar 1999 10:05:38 -0800 (PST) From: Matthew Dillon Message-Id: <199903211805.KAA13805@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 :> :the assembly wouldn't be needed. Hmm... actually... if one were to mmap() a :> :stack and as soon as the rfork() returned movl newstack,%esp and whatnot, :> :wouldn't this be a pretty simple solution? :> :> No, because one of the processes may overrun the stack before the other :> one managed to return from rfork(). The child process cannot use the :> old stack at all. : :Why would a simple movl be using the stack? If you are making a subroutine *call* to the rfork() routine, where do you think the return PC address is stored? On the stack. The rfork() routine is going to 'ret' *after* doing the rfork syscall. 'ret' pops the stack. While this in itself is not modifying the stack, you can still wind up with the situation where process A returns from the rfork and then does something else which overwrites the stack before process B has a chance to return from the rfork(). This is why, in my assembly example, I was forced to make the syscall manually rather then call the rfork() library function. :> : Brian Feldman _ __ ___ ___ ___ -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message