Date: Mon, 5 Oct 2009 20:06:10 -0400 (EDT) From: Daniel Eischen <deischen@freebsd.org> To: Matthew Fleming <matthew.fleming@isilon.com> Cc: freebsd-stable@freebsd.org Subject: Re: libthr and daemon() Message-ID: <Pine.GSO.4.64.0910052001220.9867@sea.ntplx.net> In-Reply-To: <06D5F9F6F655AD4C92E28B662F7F853E03217DCE@seaxch09.desktop.isilon.com> References: <06D5F9F6F655AD4C92E28B662F7F853E03217DCE@seaxch09.desktop.isilon.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.64.0910052001220.9867>