On Tue, Jan 02, 2007 at 02:01:02PM -0800, Justin Erenkrantz wrote: > One of the bottlenecks that keeps popping up in Subversion is the speed of > the MD5 checksums. OpenSSL has put in some work to have optimized MD5 > implementations and with David's recent work to detect OpenSSL. we can just > defer to their implementations. For AMD64/EMT64 CPUs, we can leverage > their optimized implementation (which goes from ~250MB/sec to ~370MB/sec). > > However, the big annoying thing is that we declared apr_md5_ctx_t in > apr_md5.h so it's not an opaque value. Luckily for us though, > OpenSSL's MD5 context is smaller than APR's - so an ugly hack works.
This would need to have some severe future-proofing to be safe against any change to MD5_CTX in future versions of OpenSSL, e.g. only using it for the specific sizeof() that structure as currently defined. (that would cover the cases where MD5_LONG is currently not 32-bit too) 1. is having an ENOTIMPL _set_xlate really an excusable regression? 2. is it intended that the return values from the OpenSSL MD5_* functions are ignored? (can those functions even use the OpenSSL error stack and all the mess that entails?) 3. does this mean that apr_md5_* can only be guaranteed to work after apu_ssl_init() has been called? joe
