I'm not saying that OpenSSL could not handle simultanious reads /
writes, but hope to offer you a good alternative, with maybe only a
little hair loss...
If the amount of mutexs wasn't so ghastly this could be done by OpenSSL.
The underlying communication protocol is also subject to the same
limitation, data can only be read or written, not both at the same time,
however by the time you deal with a file descriptor, this is possible.
This is because the operating system does some magic, so why can't you
do the same?
Of course I have no idea of what the OS does, but what follows might
just be a good enough replacement for the level of things.
if you have 1 read thread (r) and 1 write thread (w), introduce a new
multiplexor thread (m)
get m to acquire a r-mutex and w-mutex, then select() or poll() for read
or write on the SSL file descriptor.
in the mean time get r and w to acquire r-mutex2 and w-mutex2 and then
wait for acquisition of r-mutex and w-mutex respectively.
when w gets ready for read, release r-mutex, so r will continue, and
wait for r-mutex2, which r has
r then reads the data, releases r-mutex an d r-mutex2( thus m continues
) and r retries for r-mutex.
m, having got r-mutex2, releases and goes round the loop again
w is much like r.
Upon careful inspection another mutex is needed to ensure m gets r-mutex
before r retries, but hey thats only 6 mutex's and enough logic to make
most people's head turn.
Actually you can probably pick many more holes in this but the theory is
sound - enough mutexs and a controlling thread can sort out most things.
Hope this helps,
dgym bailey
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
