From owner-freebsd-threads@FreeBSD.ORG Mon Oct 24 14:45:35 2005 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 980FC16A41F; Mon, 24 Oct 2005 14:45:35 +0000 (GMT) (envelope-from sven@serv1-mk3.ilse.net) Received: from serv1-mk3.ilse.net (serv1-mk3.ilse.net [62.69.160.41]) by mx1.FreeBSD.org (Postfix) with ESMTP id F3A5643D48; Mon, 24 Oct 2005 14:45:34 +0000 (GMT) (envelope-from sven@serv1-mk3.ilse.net) Received: (from sven@localhost) by serv1-mk3.ilse.net (8.12.11/8.12.11) id j9OEjTkn052060; Mon, 24 Oct 2005 16:45:29 +0200 (CEST) (envelope-from sven) Date: Mon, 24 Oct 2005 16:45:29 +0200 From: Sven Berkvens-Matthijsse To: Daniel Eischen Message-ID: <20051024144529.GP22568@ilse.net> References: <20051024140023.GM22568@ilse.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-URL: http://www.ilse.nl/ User-Agent: Mutt/1.5.9i Cc: Marc Olzheim , freebsd-threads@freebsd.org, Marc Olzheim , David Xu , Sven Berkvens-Matthijsse Subject: Re: threads/76690: fork hang in child for (-lc_r & -lthr) X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2005 14:45:35 -0000 > WRT to malloc() and free() within libc_r, it is always single > threaded from the library's perspective because no other threads can > be active at the time of the fork (libc_r is all userspace threads). Correct. It also takes care to disable the signal handler that may cause a thread switch in the "thread kernel". > Probably all that needs to be done is take the malloc lock before > forking and release it afterwards (like libpthread). That's possible (and indeed what I do). I decided to lock the other locks as well because programs (buggy or not) may call those library functions after the fork (in the child) as well. We can remove those locks if you wish, none of the functions involved are async-signal-safe, and programs shouldn't be using them after a fork() in a threaded program. > It may even be enough just to set __isthreaded to 0 in the child > after the fork() before calling any malloc()'s and free()'s so they > don't try to use the lock. But then the free() in the child process may be using an unstable state of the malloc system (because if you don't acquire the lock before the fork(), malloc() may be busy in the middle of the fork()). > If __isthreaded is 0 in the child, I don't think any part of libc > will attempt to use locking. That's correct. > If the child tries to create any threads, then bad things may > happen, but that's the application's fault. True. > -- > DE -- Sven