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