From owner-freebsd-stable@FreeBSD.ORG Tue Oct 6 00:06:12 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7827C106568B for ; Tue, 6 Oct 2009 00:06:12 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id 38FB18FC12 for ; Tue, 6 Oct 2009 00:06:11 +0000 (UTC) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.3/8.14.3/NETPLEX) with ESMTP id n9606AQa013691; Mon, 5 Oct 2009 20:06:10 -0400 (EDT) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.2.2 (mail.netplex.net [204.213.176.10]); Mon, 05 Oct 2009 20:06:10 -0400 (EDT) Date: Mon, 5 Oct 2009 20:06:10 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Matthew Fleming In-Reply-To: <06D5F9F6F655AD4C92E28B662F7F853E03217DCE@seaxch09.desktop.isilon.com> Message-ID: References: <06D5F9F6F655AD4C92E28B662F7F853E03217DCE@seaxch09.desktop.isilon.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-stable@freebsd.org Subject: Re: libthr and daemon() X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2009 00:06:12 -0000 On Mon, 5 Oct 2009, Matthew Fleming wrote: > I have some code that tries to use pthread_cond_wait() and it's getting > back EPERM. Upon further investigation, here's what I've found: > > When the app starts, libthr's _libpthread_init calls init_main_thread() > to set the thread id in struct pthread's tid. Is the application threaded before calling daemon()? > The app opens a log file then calls daemon(). > daemon() calls fork() > fork() does not appear to be linked to _fork() in libthr; see below. > The app creates a thread to handle signals. > The app attempts to wait on a condition variable (pthread_cond_wait(); > this gives EPERM). Was the condition variable created before daemon() was called? The picture is not clear to me. POSIX states that only async-signal-safe function calls can be made from a child fork()'d from a threaded application. The intent is that the child should soon after call a function in the exec() family. Certainly, any more threaded calls in the child are invalid. -- DE