Closed kpamnany closed 10 months ago
Merging #265 (9d9a5a5) into master (e84f973) will increase coverage by
0.36%
. The diff coverage is100.00%
.
@@ Coverage Diff @@
## master #265 +/- ##
==========================================
+ Coverage 73.49% 73.86% +0.36%
==========================================
Files 12 12
Lines 732 750 +18
==========================================
+ Hits 538 554 +16
- Misses 194 196 +2
Files | Coverage Δ | |
---|---|---|
src/ssl.jl | 71.88% <100.00%> (+1.03%) |
:arrow_up: |
The CI failures for Julia nightly are:
ERROR: LoadError: conversion to pointer not defined for Base.CodeUnits{UInt8, String}
They're coming from crypt!
in cipher.jl
here, which I haven't touched in this PR.
There are so many random pointer
calls here that only serve to ensure incorrectness and serve no other value
We've observed
mbedtls_ssl_read
andmbedtls_ssl_write
show up in CPU profiles while also seeing long GC time-to-safepoint. Theseccall
s call back into Julia (f_send
andf_recv
), during which GC should be able to run. But I can't tell if, for large enough reads or writes, there could be a long interval without reaching a GC safepoint.Adding GC-safe regions around the
ccall
s will let GC run even if a thread is busy inside. Sincec_send
andc_recv
are@cfunction
s, they will do the right thing wrt GC safety.Ref: https://github.com/JuliaLang/julia/issues/51574
This is a temporary fix; when https://github.com/JuliaLang/julia/pull/49933 lands, this should be changed to do whatever that requires.
If a reviewer knows for certain that a thread won't remain inside the
ccall
without calling back into Julia for multiple seconds, then this PR can be discarded.