This is an archive of the discontinued LLVM Phabricator instance.

[clangd] Update TUStatus api to accommodate preamble thread
ClosedPublic

Authored by kadircet on Mar 17 2020, 11:13 AM.

Details

Summary

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.

Diff Detail

Event Timeline

kadircet created this revision.Mar 17 2020, 11:13 AM
sammccall added inline comments.Mar 17 2020, 3:09 PM
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?

264

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;
272

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 }?
It seems Name will never be used, RunningAction/Queued are not possible etc.

kadircet updated this revision to Diff 251022.Mar 18 2020, 2:43 AM
kadircet marked 8 inline comments as done.
  • 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

264

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?

272

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.

sammccall accepted this revision.Mar 18 2020, 5:00 AM
sammccall added inline comments.
clang-tools-extra/clangd/TUScheduler.cpp
264

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 :-)

360

StatusManager -> Status

493

StatusManager -> Status

707

(might be clearer to call once and make the logic conditional)

1063

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.
I'd suggest LastBuild and dropping the comment.

This revision is now accepted and ready to land.Mar 18 2020, 5:00 AM
kadircet updated this revision to Diff 252248.Mar 24 2020, 2:01 AM
kadircet marked 14 inline comments as done.
  • Address comments
kadircet added inline comments.Mar 24 2020, 2:07 AM
clang-tools-extra/clangd/TUScheduler.cpp
264

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.

sammccall accepted this revision.Mar 24 2020, 5:34 AM
This revision was automatically updated to reflect the committed changes.