From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 22 14:23:04 2006 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7CE4D16A401; Wed, 22 Mar 2006 14:23:04 +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 1E89143D46; Wed, 22 Mar 2006 14:23:04 +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.5/8.13.5/NETPLEX) with ESMTP id k2MEN36D007472; Wed, 22 Mar 2006 09:23:03 -0500 (EST) Date: Wed, 22 Mar 2006 09:23:02 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Divacky Roman In-Reply-To: <20060322140551.GA42554@stud.fit.vutbr.cz> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) Cc: hackers@freebsd.org, Volker Stolz Subject: Re: 6.1 libpthread: pthread_create and _pq_insert_tail: Already in priority queue X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Mar 2006 14:23:04 -0000 On Wed, 22 Mar 2006, Divacky Roman wrote: > On Wed, Mar 22, 2006 at 11:24:36AM +0100, Volker Stolz wrote: > > A rather largish application (the most recent version of GHC, see lang/ghc) > > fails in its runtime system with: > > > > _pq_insert_tail: Already in priority queue > > two pointers: > > 1) I use ghc daily without this problem > 2) I got this error when I was playing with threads/mutexes and my code was > wrong And what Julian said in a previous email was correct. POSIX only guarantees that async-signal-safe functions may be safely used in a child after a fork() from a multi-threaded process. Think about it. A fork() from a multi-threaded process is just as asynchronous with respect to the other threads as an asyncronous signal in a single-threaded process. Internal libc, libpthread, and process state, as well as state from any other libraries that are used, is left in an inconsistent state. An application can use pthread_atfork(), but POSIX does not require the implementation to do the equivalent (in libc, libpthread, ...) -- DE