On Mon, 19 Apr 2010 11:09:33 -0700
"Jeremy Farrell" wrote:
> That's the usual way to handle significant numbers of connections.
> For many programs handling a small number of connections, two threads
> per connection is the normal approach. It's simpler, and much easier
> to port between OSes. Ho
> > > However do you really need to use multiple concurrent threads
> > > with the same SSL object? Think of it as a TCP socket, each
> > > thread has a list of open sockets, or SSL objects, there is
> > > no need to share it with other threads.
>
> "David Schwartz" wrote:
> >
> > Actually, it's
Hi Sads,
On Mon, Apr 19, 2010 at 3:32 AM, Sad Clouds
wrote:
> On Sun, 18 Apr 2010 21:11:40 -0700
> "David Schwartz" wrote:
>> Sad Clouds wrote:
>>
>> > > 1) According to the FAQ, "an SSL connection may not concurrently
>> > > be used by multiple threads". Does this mean that an SSL
>> > > conne
On Sun, 18 Apr 2010 21:11:40 -0700
"David Schwartz" wrote:
>
> Sad Clouds wrote:
>
> > > 1) According to the FAQ, "an SSL connection may not concurrently
> > > be used by multiple threads". Does this mean that an SSL
> > > connection can be used by different threads provided access is
> > > li
Sad Clouds wrote:
> > 1) According to the FAQ, "an SSL connection may not concurrently be
> > used by multiple threads". Does this mean that an SSL connection can
> > be used by different threads provided access is limited to one at a
> > time?
> I assume that having a mutex for each SSL objec
Please note, I don't know the insides of OpenSSL, but I do a lot of
multithreaded programming on Unix, so the following are not authorative
answers, just my own opinions:
> 1) According to the FAQ, "an SSL connection may not concurrently be
> used by multiple threads". Does this mean that an SSL
