From owner-freebsd-threads@FreeBSD.ORG Thu Aug 3 20:19:45 2006 Return-Path: X-Original-To: freebsd-threads@freebsd.org Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 71EA716A51E; Thu, 3 Aug 2006 20:19:45 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 56D5D43D82; Thu, 3 Aug 2006 20:19:31 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.ntplx.net (8.13.7/8.13.7/NETPLEX) with ESMTP id k73KJTJN016165; Thu, 3 Aug 2006 16:19:30 -0400 (EDT) Date: Thu, 3 Aug 2006 16:19:29 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Poul-Henning Kamp In-Reply-To: <50596.1154635700@critter.freebsd.dk> Message-ID: References: <50596.1154635700@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) Cc: FreeBSD-gnats-submit@freebsd.org, freebsd-threads@freebsd.org 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:19:45 -0000 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