mirror of
https://github.com/salsa-rs/salsa.git
synced 2025-01-15 01:39:25 +00:00
A generic framework for on-demand, incrementalized computation. Inspired by adapton, glimmer, and rustc's query system.
20c7834ff3
428: salsa-2022: fix hanging cancellations due to cvar not being notified r=nikomatsakis a=manapointer
This PR fixes an issue with the `cvar` condvar field of `Shared<DB>` not being notified when `Arc<Shared<DB>>`s were getting dropped.
Previously, the condvar was being notified here:
```rust
impl<DB> Drop for Shared<DB>
where
DB: HasJars,
{
fn drop(&mut self) {
self.cvar.notify_all();
}
}
```
However, because this is implemented on `Shared<DB>`, the `drop` code only ran after all `Arc<Shared<DB>>`s (including that of the actual database and not just its snapshots) had dropped first, even though the intention was for the `drop` code to run when each individual `Arc<Shared<DB>>` was dropped so that the condvar would be notified each time.
To fix this, I've modified the `Shared<DB>` struct to instead hold `Arc`s to both the jars and the condvar, and `Storage` now holds `Shared<DB>` directly rather than `Arc<Shared<DB>>`. When `Shared<DB>` is dropped, it first drops its `Arc` for the jars, and then notifies the condvar.
## Note
On my local branch I have a test case for this functionality, although it relied on timing using `std:🧵:sleep`. I figured this was less than ideal, so I decided not to include it in this PR - I'd love to get feedback on a better way to test this!
Co-authored-by: manapointer <manapointer@gmail.com>
Co-authored-by: Niko Matsakis <niko@alum.mit.edu>
|
||
---|---|---|
.github/workflows | ||
book | ||
components | ||
examples | ||
examples-2022 | ||
salsa-2022-tests | ||
src | ||
tests | ||
.dir-locals.el | ||
.gitignore | ||
bors.toml | ||
Cargo.toml | ||
FAQ.md | ||
LICENSE-APACHE | ||
LICENSE-MIT | ||
README.md | ||
RELEASES.md | ||
rustfmt.toml |
salsa
A generic framework for on-demand, incrementalized computation.
Obligatory warning
Very much a WORK IN PROGRESS at this point. Ready for experimental use but expect frequent breaking changes.
Credits
This system is heavily inspired by adapton, glimmer, and rustc's query system. So credit goes to Eduard-Mihai Burtescu, Matthew Hammer, Yehuda Katz, and Michael Woerister.
Key idea
The key idea of salsa
is that you define your program as a set of
queries. Every query is used like function K -> V
that maps from
some key of type K
to a value of type V
. Queries come in two basic
varieties:
- Inputs: the base inputs to your system. You can change these whenever you like.
- Functions: pure functions (no side effects) that transform your inputs into other values. The results of queries are memoized to avoid recomputing them a lot. When you make changes to the inputs, we'll figure out (fairly intelligently) when we can re-use these memoized values and when we have to recompute them.
Want to learn more?
To learn more about Salsa, try one of the following:
- read the heavily commented
hello_world
example; - check out the Salsa book;
- watch one of our videos.
Getting in touch
The bulk of the discussion happens in the issues and pull requests, but we have a zulip chat as well.