This helps us prevent races when scheduler (or any other thread) tries
to read a request while it's still running.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
| clang-tools-extra/clangd/TUScheduler.cpp | ||
|---|---|---|
| 278 | I'd consider making this an llvm::Optional<Request> and using it as storage too. Even though it won't be accessed directly outside the main loop, I think it makes it easier to reason about the code: it emphasizes the parallel with Requests and minimizes the spooky-flags-at-a-distance effect. | |
| 611–614 | what if the currently-running task is a write? | |
| 722–723 | maybe assert there's no running task here? | |
| clang-tools-extra/clangd/unittests/TUSchedulerTests.cpp | ||
| 403 | does this deliberately match "b" below? if not, change back to something unique? | |
| 406 | This looks racy to me. What guarantees that the worker thread pulls this item off the queue and into the "running" slot before the second updateWithDiags? | |
- Address comments
| clang-tools-extra/clangd/unittests/TUSchedulerTests.cpp | ||
|---|---|---|
| 403 | no it wasn't intentional just copy paste .. | |
I'd consider making this an llvm::Optional<Request> and using it as storage too. Even though it won't be accessed directly outside the main loop, I think it makes it easier to reason about the code: it emphasizes the parallel with Requests and minimizes the spooky-flags-at-a-distance effect.