From owner-freebsd-threads@FreeBSD.ORG Thu Aug 3 20:20:38 2006 Return-Path: X-Original-To: freebsd-threads@hub.freebsd.org Delivered-To: freebsd-threads@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0D52216A4FE for ; Thu, 3 Aug 2006 20:20:38 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id EB2A343DC7 for ; Thu, 3 Aug 2006 20:20:19 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k73KKJn3021814 for ; Thu, 3 Aug 2006 20:20:19 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k73KKJiq021813; Thu, 3 Aug 2006 20:20:19 GMT (envelope-from gnats) Date: Thu, 3 Aug 2006 20:20:19 GMT Message-Id: <200608032020.k73KKJiq021813@freefall.freebsd.org> To: freebsd-threads@FreeBSD.org From: Daniel Eischen Cc: Subject: Re: threads/101323: fork(2) in threaded programs broken. X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2006 20:20:38 -0000 The following reply was made to PR threads/101323; it has been noted by GNATS. From: Daniel Eischen To: Poul-Henning Kamp Cc: FreeBSD-gnats-submit@freebsd.org, freebsd-threads@freebsd.org Subject: Re: threads/101323: fork(2) in threaded programs broken. Date: Thu, 3 Aug 2006 16:19:29 -0400 (EDT) On Thu, 3 Aug 2006, Poul-Henning Kamp wrote: > In message , Daniel Eischen wr > ites: > > >> There's no easy way to hold all library locks. They are >> littered in libc and libpthread and the application doesn't >> have access to them. You would have to teach libc to >> record these locks and export a function to lib >> to lock and unlock these them. > > I would be perfectly happy if libpthread would just at the very > least release the locks it specifically grabs for the fork. > > There's a big difference between giving it a sensible shot and > downright sabotaging it the way we do currently. Actually, I would prefer to emit an error message of the form: "fork() from a threaded process is not defined by POSIX" and purposefully segfault ;-) > Anyway, apart from the view from the theoretical high ground and > the fact that POSIX doesn't actually say anything helpful here, are > there any objections to the fix I proposed ? For that one specific change, no objection. I have an objection to enabling the NOTYET in thr_kern.c without having an overall solution for libc as well. -- DE