[cl-plus-ssl-devel] concurrency problems when used with chrome?
Anton Vodonosov
avodonosov at yandex.ru
Tue May 24 13:54:21 UTC 2011
24.05.2011, 17:25, "Attila Lendvai" <attila.lendvai at gmail.com>:
> a pure speculation about a possible optimization: maybe chrome
> preemptively opens several connections to build up the SSL handshaking
> in them, so that later on requests can be finished with lower delays?
> then at the end closes these connections when it sees that the
> downloaded content doesn't need any new requests?
I don't know. This assumption seems possible.
> as of the attached patch: i'd need something along these lines (e.g.
> stream-error subclasses being signaled when errors come from stream
> operations), but it has some controversial changes. for example gluing
> ssl-signal-error for usage with streams only as opposed to using it in
> lower-level ssl code.
Handling the ssl-error-zero-return, as David suggested in the previous message,
should work without your patch.
See for example streams.lisp, the functions stream-read-sequence,
stream-read-byte. Signaling ssl-error-zero-return from ssl-read,
corresponds to the original behavior of the C function SSL_read.
> the patch also has some random unrelated notes and a fix, too.
I agree that calling (err-get-error) when the condition is printed is not correct.
The stream-fd function is a necessary thing, so that we may provide the
socket file descriptor to OpenSSL.
Best regards,
- Anton
More information about the cl-plus-ssl-devel
mailing list