Just a thought. Would it not be possible for the SSL session to create a mutex and lock it where required?
Error details could be stored in Thread Local Storage to obliviate the need to call SSL_get_error() within the mutex block.
Regards,
John
-----Original Message-----
From: openssl-users <openssl-users-bounces@xxxxxxxxxxx> On Behalf Of John Unsworth
Sent: 07 May 2019 09:06
To: openssl-users@xxxxxxxxxxx
Subject: RE: SSL_read() returning SSL_ERROR_SYSCALL with errno 11 EAGAIN
CAUTION: This email originated from outside of Synchronoss.
Thanks, the mutex is tied to the SSL session and used for all calls (now!).
The good news is that moving SSL_get_error() into the same mutex unit as SSL_read() has solved the problem.
Thank you for all your help and advice.
Regards,
John.
-----Original Message-----
From: openssl-users <openssl-users-bounces@xxxxxxxxxxx> On Behalf Of Viktor Dukhovni
Sent: 03 May 2019 23:04
To: openssl-users@xxxxxxxxxxx
Subject: Re: SSL_read() returning SSL_ERROR_SYSCALL with errno 11 EAGAIN
CAUTION: This email originated from outside of Synchronoss.
On Fri, May 03, 2019 at 09:34:14AM +0000, John Unsworth wrote:
> Testing changed code.
For the record, though I think you realise this, *both* the SSL_read()
or SSL_write() and the following SSL_get_error() need to be protected
as a unit by the *same* instance of the locked mutex. It would not
be enough to lock these separately.
acquire_lock();
if (reading)
ret = SSL_read(ssl, ...);
else
ret = SSL_write(ssl, ...);
if (ret <= 0)
err = SSL_get_error(ssl, ret);
release_lock();
/* Handle EOF and errors */
--
Viktor.
