>bertie> BTW: You never replied to the mail with subject "Requiring >bertie> multithreaded apps to provide dynamic locking upcalls" was >bertie> this because you agreed with it :-) > >Not really. It's more like "haven't quite had the time to really read >it, have marked it for later processing"... I will respond to one >small part, however: you're suggesting breaking the API for 0.9.7. >However, we're at the end of the release cycle, and making such a >break is a rather large effort, and would basically mean that the >release cycle would start over. Therefore, I must say that it won't >happen for 0.9.7. I'll ponder over this for 0.9.8.
Yes, I meant to apologise earlier for this eleventh hour testing of the chil engine code. I wish I had looked at it a few months ago. In view of the fact that the chil engine code is only threadsafe if the dynlock callbacks are implemented, and that it is unlikely that openssl application developers will get round to providing these solely for the benefit of the chil engine would it be please be possible (I'm begging) to apply the part of the patch (#381) I supplied which allows the chil engine to use one static lock if dynlocks are not supported by the app. This patch could be reversed (in 0.9.8 ?) when it is clear to multithreaded app developers that they need to supply dynlock upcalls for threadsafety. As it stands I forsee nCipher will be back to shipping a patch for OpenSSL 0.9.7 to customers to support chil in multithreaded apps, which would be sad. Bertie ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
