Closed sbinet closed 2 years ago
Merging #923 (6f88941) into main (c38575f) will increase coverage by
0.01%
. The diff coverage is84.21%
.
@@ Coverage Diff @@
## main #923 +/- ##
==========================================
+ Coverage 73.75% 73.77% +0.01%
==========================================
Files 404 404
Lines 48554 48541 -13
==========================================
Hits 35812 35812
+ Misses 10460 10451 -9
+ Partials 2282 2278 -4
Impacted Files | Coverage Δ | |
---|---|---|
xrootd/file.go | 74.60% <84.21%> (+12.76%) |
:arrow_up: |
Continue to review full report at Codecov.
Legend - Click here to learn more
Δ = absolute <relative> (impact)
,ø = not affected
,? = missing data
Powered by Codecov. Last update c38575f...6f88941. Read the comment docs.
I want to understand this mutex lock a bit more. Is it not possible to read from a xrootd file handler in parallel?
The lock can be held by an arbitrary number of readers or a single writer. The zero value for a RWMutex is an unlocked mutex.
I think the answer is yes. But I don't know how it plays with the extern
C call.
it should. (IIRC, there's a test for that, with the -race
detector).
what the mutex protects is the "session ID" (and a cached value of the remote "file info").
"session ID" is some UUID-like identifier used internally by xrootd (client and server) to multiplex operations.
I think the answer is yes. But I don't know how it plays with the extern C call.
depending on how you call into go-hep/xrootd (presumably by generating a .so that wraps a Go type and exposes C-funcs), it shouldn't be an issue.
thanks. I would call this function from different threads. I will check if it works by looking at performance I guess
This CL reduces the lock contention on xrootd.File operations.
and now:
compared to:
Updates #920.