[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