From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18640 invoked by alias); 13 Sep 2004 04:18:26 -0000 Mailing-List: contact glibc-bugs-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Post: List-Help: , Sender: glibc-bugs-owner@sources.redhat.com Received: (qmail 18619 invoked by uid 48); 13 Sep 2004 04:18:24 -0000 Date: Mon, 13 Sep 2004 04:18:00 -0000 Message-ID: <20040913041824.18618.qmail@sourceware.org> From: "dennis at mds dot rmit dot edu dot au" To: glibc-bugs@sources.redhat.com In-Reply-To: <20040910004801.378.dennis@mds.rmit.edu.au> References: <20040910004801.378.dennis@mds.rmit.edu.au> Reply-To: sourceware-bugzilla@sources.redhat.com Subject: [Bug nptl/378] posix_spawn implementation, use vfork/execve rather than fork/execve for NPTL Linux. X-Bugzilla-Reason: CC X-SW-Source: 2004-09/txt/msg00073.txt.bz2 List-Id: ------- Additional Comments From dennis at mds dot rmit dot edu dot au 2004-09-13 04:18 ------- Interesting debate going on. It should be noted that the Solaris 10 posix_spawn (which uses vfork only) most definately does not run atfork handlers. It is listed in their posix_spawn man page, quote The fork handlers are not run when posix_spawn() or posix_spawnp() is called. So a glibc NPTL posix_spawn vfork path should not run atfork handlers. >>From what I have read also it doesn't make sense, pthread_atfork is tied to the fork function call, vfork should not care about atfork handlers. Any application developer that relies on the atfork handler posix_spawn side effect is going to be in some trouble when they use posix_spawn on Solaris 10. Personally speaking the side-effect free vfork based posix_spawn seems more inline with the ideals behind posix_spawn, that being to create a process from thin air in a fast manner. Who knows one day it might make its way closer to the kernel as a true system call (or a variant of clone). I believe GNU Hurd has its own implementation of posix_spawn (not based on fork/exec). Maybe the fact that atfork is handled in the current generic glibc posix_spawn may cause future problems? As for the flag name, how about 'POSIX_SPAWN_NPTL_USEVFORK' or 'POSIX_SPAWN_NPTL_NO_ATFORK'? We are still keen on having a vfork posix_spawn fast path (with no atfork handling similar to Solaris 10). Dennis. -- http://sources.redhat.com/bugzilla/show_bug.cgi?id=378 ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.