Please mind the single line where Darryl mentioned renegotiation/rekeying of your SSL session. It means you may have to replicate the relevant bits of code in both read and write thread. (It's the SSL_WANT_READ and SSL_WANT_WRITE codes coming out of SSL_write() and SSL_read() respectively that are going to do you in otherwise. You can test this using the OpenSSL provided sample client by hitting 'R' to force a reneg and see what your code does. Yours wouldn't be the first nor last to lock up in that scenario. The lifetime of the SSL connection is one of the factors that can trigger a reneg under the hood IIRC; anyway, you should (must) assume you're not in full control server-side at app code level regarding reneg occurring.
Otherwise, it's indeed 'critical sectioning' each SSL call through mutexes all the way to give this a chance to work. (Assuming you can _guarantee_ those read AND write threads will definitely run on the same CPU in a MPU server environment; if you can't, you're risking being DOA even while mutexing the whole bunch: if cpu A doesn't write-through cache so cpu B gets to see the same content instantaneously (i.e. the 'volatile' mentioned before, and no, SSL doesn't add 'volatile' to the internals), you're in for a few surprises that are bloody hard to debug. And generally, that type of bug waits for you to go to production. ;-) -- Met vriendelijke groeten / Best regards, Ger Hobbelt -------------------------------------------------- web: http://www.hobbelt.com/ http://www.hebbut.net/ mail: [EMAIL PROTECTED] mobile: +31-6-11 120 978 -------------------------------------------------- ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
