Closed cueckoo closed 1 year ago
Original reply by @myitcv in https://github.com/cuelang/cue/issues/652#issuecomment-763909803
Further analysis: LookupPath
also races with a Fill
call. Which may or may not point to a problem in the code path LookupPath
is following if it's reading that same state?
Original reply by @mpvl in https://github.com/cuelang/cue/issues/652#issuecomment-766156066
Analysis: the race is caused by the reference cycle detection, which modifies fields in Vertex even when it is already Finalized.
So to fix this, the reference cycle detection algorithm needs to be changed. One idea is the following: the fields are only necessary to detect the cycle for fields that are already finalized; the first time the cycle is found, it uses a different mechanism. There is a possible optimization where identical arcs (i.e. those that evaluate without an error after the cycle detection) are evaluated once and share the same data structure. This is a great optimization. But it seemingly also would obviate the need for the additional cycle check, the one that causes things to be not thread-safe.
The following would be needed to implement structure sharing:
This should have been fixed. Many concurrency fixes have gone in.
Verified this particular one.
Originally opened by @myitcv in https://github.com/cuelang/cue/issues/652
What version of CUE are you using (
cue version
)?Does this issue reproduce with the latest release?
Yes
What did you do?
Note, you might need to re-run this a few times (or increase the counter limit in the
for
loop)What did you expect to see?
Success
What did you see instead?
cc @shykes
Note the above repro is using c58e0ffc4c74. However, the underlying problem also exists with
v0.3.0-alpha6
, albeit a different kind of problem (hence stack traces vary). Critically, this reproducer does not trigger the issue forv0.3.0-alpha6