Base.lock and Base.unlock not implemented for SSLContext

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

[quinnj]

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.

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]

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.

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]

Yeah, that looks fishy; fine to remove.