Making Cue safe for concurrency

[verdverm]

Using Cue in different goroutines is a valid use case that is not supported today.

What would it take to get it there?

---

Starting this discussion since has been coming up more. Hopefully this can serve as a place to capture the high level design, current impediments, and requirements to get it there.

It may be worthwhile to collect alternative methods (such as exec'n out to cue in the meantime)

[mpvl]

The core runtime (a bunch of indices) is pretty much safe for concurrency. The adt values are almost safe for concurrency: it is mostly the cycle detection algorithm that is not. The main part that is hard to make concurrent is the API itself, most notably the instance type and its handling. This type is now mostly unnecessary, but it is hard to get rid of it without introducing backwards incompatibility.

[jlongtine]

The main part that is hard to make concurrent is the API itself, most notably the instance type and its handling. This type is now mostly unnecessary, but it is hard to get rid of it without introducing backwards incompatibility.

FWIW, I'd be up for some refactoring in the stx around Instance, if we could get concurrency. I'd love to get to a place where we could evaluate a bunch of our CloudFormation stacks in parallel, and make CFN API calls in parallel to check for changed stacks, etc. That... would be super useful. :)

[cueckoo]

This discussion has been migrated to cue-lang/cue#613.

For more details about CUE's migration to a new home, please see cue-lang/cue#1078.