This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
pthreads, fork+exec, and deadlocks
- From: Aidan Van Dyk <aidan at highrise dot ca>
- To: libc-alpha at sources dot redhat dot com
- Date: Wed, 10 Sep 2003 11:38:48 -0400
- Subject: pthreads, fork+exec, and deadlocks
I'm writing a threaded application which needs to be able to run other
programs for events/notifications, etc.
Having a thread that does a "fork() + exec()" leaves me with the
situation where the glibc internal mutexes/etc cloned can allready be
locked. In particular, the one I'm concerned about is syslog_lock.
After fork(), I want to close all file descriptors, endpwent(),
closelog(), manage stdio/stderr/stdin etc. properly before doing the
exec().
Is there any way to lock/unlock/re-intialize the syslog_lock used in
openlog/closelog/vsyslog, or should I be explicitly guarding all syslog
usage with an additional application mutex for a safe fork?
Or are there better ways/models to handle exec'ing programs from large
threaded applications?
Thanks for any hints/pointers/links/etc.
a.
--
Aidan Van Dyk Create like a god,
aidan@highrise.ca command like a king,
http://www.highrise.ca/ work like a slave.