[PATCH] D76304: [clangd] Update TUStatus api to accommodate preamble thread

Kadir Cetinkaya via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Tue Mar 24 02:07:57 PDT 2020


kadircet added inline comments.


================
Comment at: clang-tools-extra/clangd/TUScheduler.cpp:277
       build(std::move(*CurrentReq));
+      bool IsEmpty = false;
+      {
----------------
sammccall wrote:
> kadircet wrote:
> > sammccall wrote:
> > > 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;
> > > ```
> > 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?
> 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 :-)
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.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D76304/new/

https://reviews.llvm.org/D76304





More information about the cfe-commits mailing list