In any event if you end up having a MUTEX, you would be better off with only one thread accessing both queues. 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.
In most cases multi threads and only one SOCKET don't really get along. Frédéric Giudicelli http://www.newpki.org ----- Original Message ----- From: "David Schwartz" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, January 06, 2004 5:56 AM Subject: RE: OpenSSL: threading question > > > Right on ! > > > > May I ask a silly question? > > Why would you do such a weird thing in the first place? (maybe we should > > have started from there) :) > > Because you might have a design where you have a pool of I/O threads and a > queue of I/O jobs. Read jobs and write jobs might be thrown into the same > queue, so it's possible two threads might get a job for the same connection > in the opposite direction. Usually you fix this by having one mutex for each > connection and protecting the calls to reads/writes by that connection > mutex. However, if you're primarily designing for OpenSSL connections, then > you probably would just consolidate the jobs into 'read job', 'write job', > 'read and write job', and only allow one job per connection. > > DS > > > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > User Support Mailing List [EMAIL PROTECTED] > Automated List Manager [EMAIL PROTECTED] > ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
