[PATCH] D43127: [clangd] Stop exposing Futures from ClangdServer operations.
Sam McCall via Phabricator via cfe-commits
cfe-commits at lists.llvm.org
Mon Feb 12 08:07:26 PST 2018
sammccall added inline comments.
================
Comment at: clangd/TUScheduler.cpp:286
} // unlock Mutex.
RequestsCV.notify_one();
}
----------------
ilya-biryukov wrote:
> Change to `notify_all()`? Otherwise we might wake up some thread waiting on `blockUntilIdle()`, but not the worker thread.
Done.
In fact I had changed this to `notify_all`, and changed it back because it's safe:
- this class isn't threadsafe
- therefore there are only two interesting threads, the caller thread and the worker thread
- each thread can only wake up the other one, so there's no unsatisfied waiter
But as discussed offline, notify_all() is just a less surprising default, and will fail in more obvious ways when we write threading bugs.
================
Comment at: clangd/Threading.h:68
+ Deadline D, Func F) {
+ std::unique_lock<std::mutex> Lock(Mutex);
+ if (D)
----------------
ilya-biryukov wrote:
> sammccall wrote:
> > ilya-biryukov wrote:
> > > Maybe keep the locking part out of this helper? It's often desirable to hold the lock after `wait()`. This will model how `std::condition_variable::wait` is defined.
> > I tried this, but find the API just way too grungy - we need to pass a `unique_lock<std::mutex>&`?
> > Generally I'd hope we're aiming for something a little higher level than the standard library!
> >
> > We don't actually ever need to do anything with the lock held. If we did, what about passing a lambda?
> The higher-level abstraction would certainly be appealing to me as well and I would welcome it.
> I don't think we get it here, though. It's actually a bit confusing that the function calls into STL's versions of wait and wait_until, has a similar name, but does a slightly different thing.
Yeah, fair enough.
================
Comment at: unittests/clangd/ClangdTests.cpp:783
public:
- NoConcurrentAccessDiagConsumer(std::promise<void> StartSecondReparse)
- : StartSecondReparse(std::move(StartSecondReparse)) {}
+ std::atomic<int> Count = {0};
----------------
ilya-biryukov wrote:
> Maybe use paren initializers? Looks a bit less curly :-)
> ```
> std::atomic<int> Count(0);
> ```
This is a member initializer, I think I have to use this syntax :-(
Repository:
rCTE Clang Tools Extra
https://reviews.llvm.org/D43127
More information about the cfe-commits
mailing list