From owner-cvs-src@FreeBSD.ORG Wed Jun 18 01:33:40 2008 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 44F841065671; Wed, 18 Jun 2008 01:33:40 +0000 (UTC) (envelope-from davidxu@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 2B4888FC20; Wed, 18 Jun 2008 01:33:40 +0000 (UTC) (envelope-from davidxu@freebsd.org) Received: from apple.my.domain (root@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m5I1Xa1I084781; Wed, 18 Jun 2008 01:33:37 GMT (envelope-from davidxu@freebsd.org) Message-ID: <48586652.2070204@freebsd.org> Date: Wed, 18 Jun 2008 09:35:14 +0800 From: David Xu User-Agent: Thunderbird 2.0.0.9 (X11/20080612) MIME-Version: 1.0 To: Maxim Sobolev References: <200806170633.m5H6XMJH084600@repoman.freebsd.org> <20080617134828.GA30076@zim.MIT.EDU> <20080617140600.GE1176@hoeg.nl> <4857D508.8070907@FreeBSD.org> In-Reply-To: <4857D508.8070907@FreeBSD.org> Content-Type: text/plain; charset=KOI8-U; format=flowed Content-Transfer-Encoding: 7bit Cc: Ed Schouten , src-committers@freebsd.org, cvs-all@freebsd.org, cvs-src@freebsd.org Subject: Re: cvs commit: src/include Makefile spawn.h unistd.h src/lib/libc/gen Makefile.inc Symbol.map exec.3 exec.c posix_spawn.c X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2008 01:33:40 -0000 Maxim Sobolev wrote: > Ed Schouten wrote: >> * David Schultz wrote: >>> I have no objections to this, but doesn't it defeat the whole >>> purpose to implement posix_spawn() as a library function that just >>> calls fork/exec? >> >> When (if?) applications start to use posix_spawn() we may decide to move >> it into the kernel at any time. It should be okay for now. > > Are there any benefits of doing it in the kernel vs. doing it via > fork+exec? > > -Maxim > I just want to make some programs to work, since Linux and Solaris both have it now. Doing it in kernel is OK, but I don't want to put it into the kernel until it is necessary since kernel code can not be swapped out. ;-) Doing in kernel may have advantages, for example, you may get ride of zoombie process recycling by hacking kernel, a library version using vfork will need parent to handle SIGCHLD and recycle zoombie process like you use popen() and system() etcs, another advantage is it won't involve rtld if a symbol needs to resolved, because vfork shares same vmspace, it might block other threads in parent process if the child process holding a rtld's reader lock, I don't know if writer lock will be held in child, I guess it won't be. if the child process get killed wrongly by someone, it might hold reader lock forever, this is the race condition. a kernel version may have trouble if something can not be easily done in kernel, though I didn't find the one can not be done in kernel at present. Regards, David Xu