-
Notifications
You must be signed in to change notification settings - Fork 228
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Concurrent map read/write in common/ast/expr.go
#881
Comments
Looks as though calling Edit: For more context, we run billions of expressions per hour (which is being optimized away). We've noticed that calling Parse() is slow; we do two optimizations and cache the resulting ASTs. Because we cache the ASTs, the resulting AST may be used with The only way we can validate expressions is to use non-caching compilation to call Check, omitting the optimization. This is okay for us: validation happens at save time and can slow down API requests, while evaluation is the hot path. |
@tonyhb can I ask why you're doing concurrent checks against the same AST? This is pretty unusual. You should just be able to cache the checked output rather than rechecking. |
Nothing other than history! We were calling |
@tonyhb I can make the check concurrency safe. I just hadn't expected that people would be concurrently checking the same AST. That said, if you cached the checked AST, then that should side-step the issue. |
It looks like some users were relying on the AST being mutable. I'll have to find another way to isolate the checked AST creation |
Describe the bug
Evaluating a program concurrently, even in different envs, may fail, when using a cached AST:
To Reproduce
Alternatively, to repro:
Any expression fails:
5+4
orevent.data.name + '-' + event.data.foo
.Expected behavior
Data races don't happen, and we can execute cached ASTs concurrently. Parsing into ASTs via antlr is slow, and we cache strings -> ASTs for speed.
The text was updated successfully, but these errors were encountered: