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