> In any event if you end up having a MUTEX, you would be better
> off with only
> one thread accessing both queues.
Well that's what the mutex gives you.
> That would even allow you to implement a priority algo, which wouldn't be
> the case with a simple MUTEX. You could give more priority to the write
> queue, etc.
You can still give more priority to the write queue with more than one
thread, just use two queues and have each thread check the write queue
first.
> In most cases multi threads and only one SOCKET don't really get along.
I'm not sure why you'd say that. For TCP, reading and writing are totally
independent. Using a pool of threads for I/O is quite common to protect
against ambush (when an operation that shouldn't block unexpectedly does) or
to take advantage of SMP machines.
If you have mostly SSL connections, you get less benefit. Usually, you just
integrate read and write jobs for SSL connections. If you only expect to
have the occasional SSL connection, you'd prefer to optimize your design for
TCP connection where reads and writes are fully independent -- in that case,
adding a per-connection mutex is a quick way to make an SSL connection work
in that model.
DS
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
