libthr and daemon()
Daniel Eischen
deischen at freebsd.org
Tue Oct 6 00:06:12 UTC 2009
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
More information about the freebsd-stable
mailing list