In my opinion a threaded model has three advantages:
- Takes advantage of multiple processors if you're doing, say, software RSA.
- Often simplifies the code.
- Works, with small overhead, for hardware accelerated RSA as well.
(I guess this is exactly what you are saying, Bodo. Just wanted to stress
this.)
/Per Nilsson
-----Original Message-----
From: Bodo Moeller <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: den 2 september 1999 00:52
Subject: Re: Revised OpenSSL hardware support
>Dr Stephen Henson <[EMAIL PROTECTED]>:
>
>>> [...] I think the idea of forcing people to use threads to obtain
>>> decent performance is unacceptable. [...]
>
>> Quite a few applications already follow the "one SSL connection per
>> thread or process" model.
>
>One reason for doing things that way (threads instead of multiplexing
>in a single thread) is that public-key operations in software
>introduce quite a bit of latency, and you don't want all other
>connections to stall when there's a handshake at one of them. So
>maybe in an ideal world it'd be possible to request that slow software
>bignum operations be "non-blocking" too in the sense that after doing
>some of their work they'd return control to the top-level, which then
>can handle other threads and continue the slow operation later.
>Or maybe in an ideal world you'd have multi-processor machines
>everywhere so that no-one would think of doing things single-threaded.
>______________________________________________________________________
>OpenSSL Project http://www.openssl.org
>Development Mailing List [EMAIL PROTECTED]
>Automated List Manager [EMAIL PROTECTED]
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
