Hiroshi NAKAMURA wrote: > I think you're confusing SecureRandom's spec and ext/openssl (formerly > ruby-pki) spec. ext/openssl aims to wrap OpenSSL that user's using so > if OpenSSL is not 'fork-safe' as Eric expected, so ruby-pki doesn't. I hope everything in Ruby (including 3rd-party extensions/gems) can be made fork-safe by default (if they run on a system with fork) one day. I don't agree with blindly mimicking OpenSSL upstream behavior if Ruby can be made easier-to-use. > So if OpenSSL can't change this behavior (I bet they can't at least in > the near future), why don't we change lib/securerandom.rb? Yes, I confirmed OpenSSL can't change the current behavior: http://marc.info/?l=openssl-dev&m=130298304903422&w=2 I'm still hoping to get a list of things that need to be reinitialized in OpenSSL after fork() from openssl-dev... > The reason why I think you're not serious is adding ptherad_atfork() > in ext is too ad-hoc-ish. We can't do it from Ruby world if I > understand correctly. Adding atfork hook first? I would be 100% in favor of making something analogous to pthread_atfork() available in Ruby. It would make it much easier to manage various resources in a multi-process situation No comment on the appropriateness of pthread_atfork() inside an ext. -- Eric Wong