From: Jean-Paul C. <ex...@di...> - 2009-03-18 20:54:37
|
On Wed, 18 Mar 2009 21:38:49 +0100, "M.-A. Lemburg" <ma...@eg...> wrote: >On 2009-03-17 19:57, M.-A. Lemburg wrote: > > [snip] > >For better or worse, we have found that even the patch on SF doesn't >fix the problem in all cases: > >While we no longer get segfaults on the second SSL request to >a server application using the patched pyOpenSSL 0.8.0, we still >get immediate segfaults if two clients try to access the server >at the same time. This time around the problem shows up on Windows. > >Only going back to pyOpenSSL 0.7 solved both issues. > >I guess the reason for this is that pyOpenSSL 0.7 stores the >thread state in the connection rather than the context as does >the SF patch. > >Do you have any information on whether the context in OpenSSL is >thread-safe ? > >The FAQ entry for OpenSSL only mentions connections: >http://www.openssl.org/support/faq.html#PROG1 > >Note that it also mentions two callbacks that have to be initialized >for multi-threaded applications: CRYPTO_set_locking_callback() and >CRYPTO_set_id_callback() which pyOpenSSL does not set. > >Unfortunately, the man page explaining these is not very helpful: > >http://www.openssl.org/docs/crypto/threads.html You've linked to all the documentation I'm aware of. My interpretation of it has been that it means Context objects are threadsafe, as long as you initialize OpenSSL's threading layer (which pyOpenSSL does in 0.8.0 but not in any previous version!). Probably reading the implementation is the only way to be really sure (though, of course, a future release of OpenSSL might invalidate anything learned using that approach). Jean-Paul |