> A look at engine::perform implementation in engine.ipp quickly shows us that... everything is fine.
Here's the beginning of perform():
::ERR_clear_error();
int result = (this->*op)(data, length);
int ssl_error = ::SSL_get_error(ssl_, result);
int sys_error = static_cast<int>(::ERR_get_error());
So the lock contention is in SSL_get_error / ERR_get_error? I see a big problem here - stop checking them on success!
int result = (this->*op)(data, length);
int ssl_error = SSL_ERROR_NONE;
int sys_error = 0;
if (result != 1) {
ssl_error = ::SSL_get_error(ssl_, result);
sys_error = static_cast<int>(::ERR_get_error());
::ERR_clear_error();
}
The move of the error clearing to right after they're retrieved, may not be completely right so the rest of the code needs to be checked. But the general idea should eliminate the lock contention completely. (unless they deal with mostly connection errors)
Are there that many situations where you can't just put a SSL proxy in front of a standard HTTP server, and keep the application itself simpler?
If I were a sysadmin in charge of just keeping in-house applications running, I'd really hate it if some SSL layer bug meant I had to figure out how to recompile some custom application - especially one using boost! - not to mention figuring out how to update certificates and that sort of thing.
There are some compliance related situations where having unencrypted data on the wire can trigger audit issues, but that's an artificial circumstance and you're correct that an SSL proxy is almost always easier to impliment.
Fancy UI or not, it is an absolutely invaluable tool when profiling code on OS X. The memory leak detector is really neat too, and has helped me numerous times track down where I am leaking memory.
> A look at engine::perform implementation in engine.ipp quickly shows us that... everything is fine.
Here's the beginning of perform():
So the lock contention is in SSL_get_error / ERR_get_error? I see a big problem here - stop checking them on success! The move of the error clearing to right after they're retrieved, may not be completely right so the rest of the code needs to be checked. But the general idea should eliminate the lock contention completely. (unless they deal with mostly connection errors)