I'm working with a web server project that performs a fork
without an exec
. The program depends upon OpenSSL, and OpenSSL needs a number of locks (CRYPTO_NUM_LOCKS
to be exact, which is about 40 at the moment). The locks are typically pthread_mutex_t
on Linux, and they are installed/created on the main thread before any threads are created.
fork
creates a new process. However, after the fork
, the handles used in the mutex are shallow copied. That is, they have the same bits but I don't believe they have a useful value in the context of the new process.
I think the general problem is that of thread and fork safety in a shared object. The OpenSSL wiki page on libcrypto
discusses thread and fork safety, and I'm not sure how to address some of the problems.
Is there a way to specify that a library (such as OpenSSL) should be re-initialized on fork
?
The mutexes won't be valid across the
fork
unless you put them in shared memory and initialize the mutex attribute withpthread_mutexattr_setpshared
set to PTHREAD_PROCESS_SHARED.It's not clear if you are forking and then creating threads or creating the threads and then forking. If the latter, then fork will only apply to the thread that calls fork. None of the other threads are created in the new process.
If you are forking and then threading and the mutexes are meant to only apply to the child process and its threads then just create them after the fork.