Currently, when one thread blocks on another, we clone the
stack from that task. This results in a lot of clones, but it also
means that we can't mark all the frames involved in a cycle atomically.
Instead, when we propagate information between threads, we also
propagate the participants of the cycle and so forth.
This branch *moves* the stack into the runtime while a thread
is blocked, and then moves it back out when the thread resumes.
This permits the runtime to mark all the cycle participants at once.
It also avoids cloning.
Instead of creating a future for each edge
in the graph, we now have all dependent queries
block in the runtime and wake up whenever results
are published to see if their results are ready.
We could certainly allocate a CondVar for each dependent
query if we found that spurious wakeups were a problem.
I consider this highly unlikely in practice.
Before we could not observe the case where:
* thread A is blocked on B
* cycle detected in thread B
* some participants are on thread A and have to be marked
(In particular, I commented out some code that seemed necessary and
didn't see any tests fail)
Rather than checking return value of from `Q::cycle_fallback`, we
now consult the computed recovery strategy to decide whether to
panic or to recover. We can thus assume that we will successfully
recover and don't need to check for `None` results anymore.
If I am not in an error, all current tests uses "static" cycles -- a
cycle always present. Let's spice that up by adding conditional cycles:
cycles that appear only for specific impls
282: Update book workflow r=nikomatsakis a=mbrobbel
I noticed the book workflow [failing](https://github.com/salsa-rs/salsa/runs/3568827495?check_suite_focus=true) on master. This PR attempts to fix the failing workflow and prevent failing book deploys in the future.
- Add the book build to `bors.toml`.
- Make sure the book workflow runs for the bors branches (`staging` and `trying`).
- Exclude the bilibili domain in the mdbook-linkcheck config to prevent the 403s.
I also bumped mdbook and mdbook-mermaid versions.
Co-authored-by: Matthijs Brobbel <m1brobbel@gmail.com>
280: Fix `invalidate` and `report_synthetic_read` r=nikomatsakis a=jonas-schievink
Fixes https://github.com/salsa-rs/salsa/issues/246
Fixes https://github.com/salsa-rs/salsa/issues/277
`report_synthetic_read` only forced the durability of the current query to some lower value, but didn't set its `changed_at` value, leading to downstream queries assuming that they could reuse the query's value when they could not. Force `changed_at` to the current revision to fix that. This will not result in unnecessary invocations of the query, because salsa still treats it as pure, and won't re-run it if its inputs are up to date.
Additionally, `invalidate` did also not set the slot's `changed_at` field, which is fixed by setting it to the newly created revision.
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
279: Remove dead code r=nikomatsakis a=jonas-schievink
This was added in fd036a4f15, but never actually came into effect.
Granting access to `QueryTableMut` for every query type should be harmless, because every method on that type has a where-clause that makes it only work with the right query storage type.
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
272: CI installs `rustfmt` where needed r=nikomatsakis a=1tgr
Only the stable toolchain appears to install `rustfmt` by default
Co-authored-by: Tim Robinson <tim.g.robinson@gmail.com>
268: Expose proc macro docs via the main crate r=nikomatsakis a=1tgr
Improve visibility by placing the `database` and `query_group` proc macros at the bottom of the main docs page, instead of manually browsing to the docs for the `salsa-macros` crate.
Co-authored-by: Tim Robinson <tim.g.robinson@gmail.com>
