On 8/22/13 12:46 PM, Nico Williams wrote:
The parent might be multi-threaded, leading to the risk that a thread in the parent and the child will obtain the same PRNG outputs until the parent thread that fork()ed completes the re-seeding.
That's a good point; I hadn't thought of that.
Also, it's not a requirement that pthread_atfork() require -lpthread. It's entirely possible (and on Solaris 10 and up, for example, it is in fact so) that pthread_atfork() is in libc.
That actually makes much more sense, since pthread_atfork() really has nothing to do with threads. But at least on Linux, pthread_atfork() is part of -lpthread.
If you are going to exec() anyways you should have used vfork(), or better! you should have used posix_spawn() or equivalent.
On Linux, posix_spawn still ends up calling the atfork handlers, if (and only if) you specify any file_actions. I was actually in an unfortunate situation recently where the atfork handlers of a closed-source OpenGL library were causing crashes, so to run an external process with output redirection, I had to posix_spawn /bin/sh (with no file_actions), and then give /bin/sh a shell command to perform the output redirections and then exec the program I really wanted to run. Ugly!
--Patrick ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
