> So the question: how many people would want non blocking I/O support? If
> no one or hardly anyone wants or needs it then there isn't a lot of
> point. However if there's considerably demand it would be worth looking
> into.
if it doesn't affect the API then i suppose, then the blocking I/O is
sufficient. the I/O is implemented through BIO's, right? if the blocking
is problem for application, then i can create separate thread for
encoding/decoding or use timeouts on underlying BIO.
btw, when we are talking about huge PKCS#7 structures it would be nice to
have option for excluding the body of the PKCS#7 message from decoded
structure or having a separate BIO for it. when the PKCS#7 message is
really 1GB big i want to be able to verify it and i want to save the
plaintext body to file in one pass. i know, its quite hard to generalize
this kind of thing :(
arne
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
