On Fri, Aug 23, 2013 at 1:12 AM, Patrick Pelletier <c...@funwithsoftware.org> wrote: > 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.
You were optimizing prematurely, and you know what they say about that :) Running atfork handlers when you're going to exec may sound silly and inefficient, but you don't really know that the child will exec(), not when writing library code (like OpenSSL's). Trying to avoid it is premature optimization. To be fair, all processes ought to exec() or exit() soon after starting on the child-side of fork(), but we all know many programs that fork() and just continue as if nothing. fork() is evil, but few know it. >> 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. Well, to be fair in Solaris 10 and up all of pthreads is in libc. POSIX doesn't specify what libraries should provide what functions. >> 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! This is all OT but, are you sure? Looking at recent-ish glibc it looks like vfork() is used when: a) you set the POSIX_SPAWN_USEVFORK attribute (not portable) or b) you didn't set sigmask, sigdef, schedparam, scheduler, pgroup, or resetids. Whereas fork() always runs the handlers. But perhaps your libc does something else. Anyways, that is obviously a bug in OpenGL, and also OT :( Nico -- ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
