Skip to content
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

Open
durban opened this issue May 7, 2024 · 4 comments
Open

Eval thread safety #4598

durban opened this issue May 7, 2024 · 4 comments

Comments

@durban
Copy link
Contributor

durban commented May 7, 2024

If we have an Eval like this:

val e = Eval.defer(Eval.always { println("foo") }).memoize

Accessing e.value concurrently from different threads sometimes prints foo twice. I'm not sure if Eval is supposed to be thread safe, but this seems like a bug.

@johnynek
Copy link
Contributor

johnynek commented May 7, 2024

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.

@durban
Copy link
Contributor Author

durban commented May 8, 2024

Fair enough. I guess then the lazy val could also be removed form Later, right?

@johnynek
Copy link
Contributor

johnynek commented May 8, 2024

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.

@rossabaker
Copy link
Member

Three alternate approaches to laziness, with various tradeoffs, are exemplified in latr.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants