TUStatus api had a single thread in mind. This introudces a section
action to represent state of the preamble thread. In the file status extension,
we keep old behavior almost the same. We only prepend current task with a
parsing includes if preamble thread is working. We omit the idle thread in the
output unless both threads are idle.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
clang-tools-extra/clangd/TUScheduler.cpp | ||
---|---|---|
162 | nit: "manager" doesn't really explain what this is, and it's used both as the class name and the main description in the comment. Maybe TUStatusTracker or something - "Threadsafe holder for TUStatus..." | |
167 | you could consider a slightly more general version: StatusMgr.update([&](TUStatus &S) { S.PreambleAction = Idle; }); it's a bit more wordy at the callsite but it makes the correspondence much more direct. | |
199 | why mutable with no const functions? | |
267 | Seems clearer to do this immediately before blocking? at the top: if (!NextReq) { Lock.unlock(); StatusManager.setPreambleAction(Idle); Lock.lock(); ReqCV.wait(NextReq || Done); } if (Done) break; | |
275 | why this change? | |
clang-tools-extra/clangd/TUScheduler.h | ||
113 | What's the purpose of this change? It seems to make the build details harder to maintain/extend. (In particular, say we were going to add a "fallback command was used" bit, where would it go after this change?) | |
121 | why TUAction rather than a PreambleAction enum { Building, Idle }? |
- Address comments
clang-tools-extra/clangd/TUScheduler.cpp | ||
---|---|---|
162 | NAMIIIING !!! :((( | |
199 | I had a readable version at some point, just leftover from those days :P | |
267 | i agree, but I wanted to keep the current semantics. we only start emitting tustatuses after thread starts executing the first request. happy to change *both* preamblethread and astworker to emit before blocking though. wdyt? | |
275 | this needs to happen after resetting CurrentReq and previously this was part of build. It makes more sense to hanlde this resetting as part of the worker thread, rather than as part of the preamble build logic. but I suppose it doesn't belong into this patch. moving it to the https://reviews.llvm.org/D76125 | |
clang-tools-extra/clangd/TUScheduler.h | ||
113 | this was to narrow down the interface. Currently builddetails is only being used to report buildstatus, and those cases are mutually exclusive(a build can't be both a reuse and failure). Therefore i wanted to make that more explicit. if we decide to add more details, I would say we should rather get BuildDetails struct back, with a Status enum and a couple more state to signal any other information. |
clang-tools-extra/clangd/TUScheduler.cpp | ||
---|---|---|
267 | I think the difference is moot - we never create either the AST or preamble worker until there's something to do. The code around scheduling/sleeping in the AST worker thread is way more complicated, and I'm not confident moving the status broadcast to the top of the loop would be clearer there. Up to you: if you think both are clearer, move both. If you think the preamble is clearer at the top and AST worker at the bottom, then you can choose between consistency and clarity :-) | |
363 | StatusManager -> Status | |
496 | StatusManager -> Status | |
710 | (might be clearer to call once and make the logic conditional) | |
1064 | nit: write this as a switch for consistency plus the covered warning? | |
clang-tools-extra/clangd/TUScheduler.h | ||
113 | OK, I understand but don't really agree - the fact that these are exclusive is a coincidence that we don't need to model APIs around. This doesn't seem related to the rest of this patch, either. I think we're going around in circles on this though, will leave this up to you. | |
121 | comment just repeats the declaration, drop it? | |
122 | I think these variables are still best described at a high level actions, not states. (Well, the state of the thread is that it is running this action, but that's a little roundabout. TUAction::State probably should have been called Kind instead). Unfortunate that we need both a type name and a variable name though. ASTAction ASTActivity; PreambleAction PreambleActivity;? | |
125 | If keeping the enum, this variable needs a real name. |
clang-tools-extra/clangd/TUScheduler.cpp | ||
---|---|---|
267 | as discussed offline, this might make tests flaky due to a possible race between this thread and the thread issuing the write. so leaving it as it is. |
What's the purpose of this change? It seems to make the build details harder to maintain/extend.
(In particular, say we were going to add a "fallback command was used" bit, where would it go after this change?)