[cl-plus-ssl-devel] concurrency problems when used with chrome?

[Attila Lendvai]

>> 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.


yeah, i was too slow to get it, sorry. meanwhile on IRC David
enlightened me about what he meant.

the condition name wasn't too intuitive, though, but i understand that
it's following openssl's naming convention.

since then i've managed to achieve what i wanted with stock cl+ssl, so
the part of my patch related to error handling can be ignored. i
needed to get hold of the underlying fd from a signaled
ssl-error/handle condition, which i've managed to do using
cl+ssl::ssl-get-fd


> The stream-fd function is a necessary thing, so that we may provide the
> socket file descriptor to OpenSSL.


it mislead me this way: i've thought that i can call it on a cl+ssl
provided stream and it will return the underlying fd. but its default
implementation (triggered when called on cl+ssl streams) quietly
returns the stream object itself. i was staring at the backtrace for a
bit to realize what's going on...

i see how it's needed internally, but i'm surprised it's exported.

thanks for all the help!

-- 
 attila

Notice your eroding (digital) freedom, and do something about it!

PGP: 2FA1 A9DC 9C1E BA25 A59C  963F 5D5F 45C7 DFCD 0A39
OTR XMPP: 8647EEAC EA30FEEF E1B55146 573E52EE 21B1FF06
BitCoin: 154uf86Vd9rpjMULd9CXa7nVwikknYZJiB