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.