mirror of
https://github.com/facebook/sapling.git
synced 2024-10-10 00:45:18 +03:00
e3c3133fd3
Summary: Futures are by default run inline, meaning that when the previous future is completed, the future will run in the same context as the previous one. In the case where the previous one is completed by another thread setting up its promise, the future will be completed in the context of that other thread. In most cases, this is OK, in others, this can cause a deadlock. And this is exactly what we're seeing here. When a file is renamed concurrently to an `hg update`, the inode the rename operates on might not be loaded, and thus both update and the rename callback will race to load that inode. When update wins that race, the rename callback will wait on a promise that update will then set. When that happens, the rest of the rename callback will be run in the update context, but that will in turn cause update to try to re-acquire the rename lock that it already holds... To fix this, we need to make sure that the rename callback doesn't run inline. Reviewed By: chadaustin Differential Revision: D24657422 fbshipit-source-id: 23b08765afae7bda4a628f0c23675bff9f486b6b |
||
|---|---|---|
| .. | ||
| benchharness | ||
| benchmarks | ||
| cli | ||
| config | ||
| docs | ||
| fuse | ||
| inodes | ||
| journal | ||
| model | ||
| monitor | ||
| notifications | ||
| prjfs | ||
| py | ||
| rocksdb | ||
| service | ||
| sqlite | ||
| store | ||
| takeover | ||
| telemetry | ||
| testharness | ||
| third-party | ||
| utils | ||
| CMakeLists.txt | ||