Date: Wed, 22 Mar 2006 09:23:02 -0500 (EST) From: Daniel Eischen <deischen@freebsd.org> To: Divacky Roman <xdivac02@stud.fit.vutbr.cz> Cc: hackers@freebsd.org, Volker Stolz <vs@freebsd.org> Subject: Re: 6.1 libpthread: pthread_create and _pq_insert_tail: Already in priority queue Message-ID: <Pine.GSO.4.43.0603220912210.10473-100000@sea.ntplx.net> In-Reply-To: <20060322140551.GA42554@stud.fit.vutbr.cz>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.43.0603220912210.10473-100000>