search

JuliaLang / MbedTLS.jl

Wrapper around mbedtls
Other
41 stars 50 forks source link

Base.lock and Base.unlock not implemented for SSLContext #233

Open ghost opened 3 years ago

ghost commented 3 years ago

Otherwise concurrent writes and reads corrupt the data, would it be worth implementing? I can take a stab at it.

quinnj commented 3 years ago

We do support some locking (see the datalock and waitlock fields in this file). Can you explain a little more your use-case and roughly what functionality you want to add? My main concerns/worries are impacting downstream use-cases performance-wise, i.e. HTTP requests and such. That's not to dissuade from improving things here, we just need to be aware that this is a "lower level" package in terms of the network stack and lots of other packages indirectly rely on this functionality.

ghost commented 3 years ago

I was trying to use it with ClusterManager as a replacement for Sockets, no such luck as the state of serializer / deserializer is corrupt. Apparently ClusterManager is using lock(::IO) to avoid concurrent writes https://github.com/JuliaLang/julia/blob/master/stdlib/Distributed/src/messages.jl#L170 which is not implemented and defaults to nothing.

quinnj commented 3 years ago

Ok, that sounds reasonable. I guess I wonder if we can implement what's necessary using the existing lock fields, or if something additional will be required. If you're willing to try things out, I'm happy to help review what ideas you have in a pull request. It might be helpful in your testing, in addition to your own use-case with ClusterManager, to run the HTTP.jl tests on your MbedTLS.jl changes, since it exercises a lot of the ssl.jl codepaths.

ghost commented 3 years ago

datalock could work but for some reason it is checking for the number of times it was locked - https://github.com/JuliaLang/MbedTLS.jl/blob/master/src/ssl.jl#L594 - if this is removed no big changes are required.

quinnj commented 3 years ago

Yeah, that looks fishy; fine to remove.