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

WIP suggestion: Simplify context lock lifetimes with lambdas #1969

Closed
wants to merge 1 commit into from

Conversation

MaximOsipenko
Copy link
Contributor

My suggestion on how to prevent double-read caused deadlocks in new/user code (and also fixes of existing ones).
The main change internally is that Context now holds Arc<Helper<Impl>> instead of Arc<RwLock<Impl>>, and Helper API consumes "transaction functors" instead of returning lock-guards. Speaking by example, ctx.input().screen_rect() now will be implemented as ctx.input(|i| i.screen_rect()).

Pros:

  1. Now it's way more clear when the Context is actually locked (only in lambda body), there is syntactically no way to extend its lock time.
  2. Now it's safe to use: locks in if-let statement, multiple locks in the same expression.
  3. Now it's little easier to read/write multiple fields under the same lock, instead of using multiple locks in the same expression.

Cons:

  1. Lambda syntax is kind of ugly for this purpose.
  2. Changes are trivial, but big and breaking the api.
  3. TBA

Notes:

  1. It's now harder to lock multiple fields at once, but that's a way to deadlock anyway.

Couple more words about feature state and motivation are placed in README.md.

Also, this PR features new "hello_world_par" example, which heavily uses Context in parallel (was used for smoke testing the branch).

Currently the code is a little bit dirty, not everything can compile, but I hope it's enough to get the idea and decide is the it worth it to develop these changes.
I expect the possibility of early rejection so I hope to get some feedback from contributors about how useful will it be before continuing development.

@emilk
Copy link
Owner

emilk commented Oct 16, 2022

Sorry for beeing so slow on this one, but I actually think this is a good idea. I've been hesitant due to the big breaking change and uglier syntax, but considering the number of deadlock issues we're seeing, I think this is the cleanest solution.

@emilk
Copy link
Owner

emilk commented Jan 24, 2023

I'm gonna pick this up and try to get it up-to-date

@emilk
Copy link
Owner

emilk commented Jan 24, 2023

Closed in favor of #2625

@emilk emilk closed this Jan 24, 2023
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

Successfully merging this pull request may close these issues.

2 participants