-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
Eval
thread safety
#4598
Comments
Memoize isn't for effects. It should always produce the correct value but in a multithreaded environment it may be evaluated more than once. Preventing that requires a lock during the eval evalution which would harm performance for those using it for the intended use case: controlling laziness and avoiding stack overflows. If you care if a race can cause the eval to be run twice probably I'd use a IO or a newtype/opaque type wrapper on IO. |
Fair enough. I guess then the |
If you mean we don't need the synchronization that lazy val gives then yes. We could reimplement a "evaluate once" semantic without any sychronization and it may be faster. If we had benchmarks to show that it was faster I'd support merging it. |
Three alternate approaches to laziness, with various tradeoffs, are exemplified in latr. |
If we have an
Eval
like this:Accessing
e.value
concurrently from different threads sometimes printsfoo
twice. I'm not sure ifEval
is supposed to be thread safe, but this seems like a bug.The text was updated successfully, but these errors were encountered: