> > The irony is that on Windows, with IOCP, it's even more common to have
> > concurrent reads and writes to the same socket handled by different
> > threads.
> > IOCP throws read and write events into the same event queue because you
> > associate a socket with a completion port!
> IOCP ? Are you talking about WinSock2 ? The WSA* functions ?
Yes.
> I should remind that the technical problem was never really, read
> and write
> from 2 threads, but more read and read from 2 threads (SSL_read and
> SSL_write).
Well, the problem is that SSL_read can require writing, so the TCP model of
independent reading and writing is not maintained. Thus I/O models that work
for TCP can fail to work for SSL. Or, to put it another way, the
SSL_read/SSL_write functions are not a drop in replacement for read/write.
> All I said was, "since you will only have one access to the
> socket, I see no
> points having two threads".
> Personally I would have one thread that picks from both queues, that would
> save resources.
Except that all but one processor would be sitting idle and if any piece of
your code ever blocked (say, due to a page fault or a windows LSP that
decided to do a blocking DNS query), your entire I/O portion would come
screetching to a halt. That is, unless you use more than one thread but only
allow one thread at a time to handle a given connection. In that case, you
need some mechanism to ensure that, which a per-connection mutex is often
perfect for.
> This is just a personnal programation view. No
> debate needed
> over this.
Well the point is that SSL does not present the same programming interface
as TCP, so the way you do I/O from your threads needs careful consideration.
If you want to handle TCP and SSL from the same thread pool using IOCP, for
example, you almost have no choice but to use a per-connection mutex.
DS
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
