From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14905 invoked by alias); 8 Mar 2004 13:10:15 -0000 Mailing-List: contact libc-hacker-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-hacker-owner@sources.redhat.com Received: (qmail 14884 invoked from network); 8 Mar 2004 13:10:12 -0000 Received: from unknown (HELO sunsite.ms.mff.cuni.cz) (195.113.19.66) by sources.redhat.com with SMTP; 8 Mar 2004 13:10:12 -0000 Received: from sunsite.ms.mff.cuni.cz (sunsite.mff.cuni.cz [127.0.0.1]) by sunsite.ms.mff.cuni.cz (8.12.8/8.12.8) with ESMTP id i28B18nd031547; Mon, 8 Mar 2004 12:01:08 +0100 Received: (from jakub@localhost) by sunsite.ms.mff.cuni.cz (8.12.8/8.12.8/Submit) id i28B153X031450; Mon, 8 Mar 2004 12:01:05 +0100 Date: Mon, 08 Mar 2004 13:10:00 -0000 From: Jakub Jelinek To: Roland McGrath Cc: Ulrich Drepper , Andreas Schwab , libc-hacker@sources.redhat.com Subject: Re: getpid/vfork broken Message-ID: <20040308110105.GN3822@sunsite.ms.mff.cuni.cz> Reply-To: Jakub Jelinek References: <404BDA36.6000202@redhat.com> <200403080237.i282bXG6004322@magilla.sf.frob.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200403080237.i282bXG6004322@magilla.sf.frob.com> User-Agent: Mutt/1.4i X-SW-Source: 2004-03/txt/msg00021.txt.bz2 On Sun, Mar 07, 2004 at 06:37:33PM -0800, Roland McGrath wrote: > The new specification for vfork where you can't even call dup2 is very > close to useless. The origin of vfork and true standard for its behavior > that applications have been written for is 4.2BSD, where simple system > calls were always safe, and getpid has always been the simplest system > call. The modern BSD specification remains that the address space is > shared, with all that entails, but since getpid has never relied on data > contents in the address space before, citing that as license to make it do > the wrong thing is dubious at best. Since the useless specification has > been enshrined in POSIX, where vfork in fact never belonged at all, it is > likely that every historical program will be broken and people will just > have to adapt to giving up vfork entirely. Progress. Here is what would be needed to make vfork & getpid work together: 1) vfork needs to: struct pthread *pd = THREAD_SELF; int oldval = THREAD_GETMEM (pd, pid); int newval = oldval ? -oldval : INT_MIN; THREAD_SETMEM (pd, pid) = newval; actual vfork syscall (oldval must be saved in a register preserved accross the syscall) THREAD_SETMEM (pd, pid) = oldval; 2) raise would need: /* raise is an async-safe function. It could be called while the fork function temporarily invalidated the PID field. Adjust for that. */ if (__builtin_expect (pid <= 0, 0)) - pid = pid == 0 ? selftid : -pid; + pid = (pid & INT_MAX) == 0 ? selftid : -pid; vfork is written in assembly for each architecture, so so that would need to be coded for each architecture. ->pid field seems to be only accessed in raise, getpid and fork from libc.so functions, when libpthread is loaded, THREAD_SELF->pid will always be non-zero, getpid with THREAD_SELF->pid == INT_MIN will always do the real syscall and while vfork is running, the same program certainly shouldn't call fork() (neither in a signal handler nor in the vfork child). Jakub