From owner-freebsd-arch Mon Oct 29 13:40:52 2001 Delivered-To: freebsd-arch@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id E36CE37B401 for ; Mon, 29 Oct 2001 13:40:50 -0800 (PST) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.11.4/8.11.4) id f9TLehw15955; Mon, 29 Oct 2001 16:40:43 -0500 (EST) (envelope-from wollman) Date: Mon, 29 Oct 2001 16:40:43 -0500 (EST) From: Garrett Wollman Message-Id: <200110292140.f9TLehw15955@khavrinen.lcs.mit.edu> To: julian@elischer.org Subject: Re: syscall() ABI questions In-Reply-To: References: <20011029151912.D14748@locore.ca> Organization: MIT Laboratory for Computer Science Cc: arch@FreeBSD.org Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In article you write: >But the API for vfork forbids the child from doing a 'ret' after the vfork >returns.. if it does that, all bets are off.... you can do: vfork() in general doesn't work. The fact that it works on current FreeBSD platforms is just a coincidence. (It's effectively switching to a different stack in the child, which happens to be located in the same place as the existing stack. If there were a real alternate stack, vfork() would at least have a chance at being reliable, but this is impossible in the general case without help from the compiler.) IWBRNI we could implement the brand-spankin'-new posix_spawn() interface, which attempts to provide the benefits of vfork (in its normal usage pattern) without making assumptions about stack usage. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message