[PATCH] D52004: [clangd] Allow all LSP methods to signal cancellation via $/cancelRequest
Kadir Cetinkaya via Phabricator via cfe-commits
cfe-commits at lists.llvm.org
Wed Sep 12 15:01:09 PDT 2018
kadircet added a comment.
Wonder if we can still keep the onCancelRequest registry within ProtocolHandler's scope, so that it is clear that we implement it. Other than that seems fascinating, thanks!
================
Comment at: clangd/JSONRPCDispatcher.cpp:246
+ auto StrID = llvm::to_string(ID); // JSON-serialize ID for map key.
+ auto Cookie = RequestCookie++;
+ std::lock_guard<std::mutex> Lock(CancelMutex);
----------------
Maybe we can say something about this method is actually being invoked in a sync manner and the reason why we have mutex below is due to context destruction of the thread we might spawn later on. Because it bugged me at first look not having this line under mutex as well, then I noticed actually this was still a sync function.
================
Comment at: clangd/JSONRPCDispatcher.cpp:248
+ std::lock_guard<std::mutex> Lock(CancelMutex);
+ RequestCancelers[StrID] = {std::move(Task.second), Cookie};
+ // When the request ends, we can clean up the entry we just added.
----------------
maybe limit the Lock's scope just to put element into map.
Repository:
rCTE Clang Tools Extra
https://reviews.llvm.org/D52004
More information about the cfe-commits
mailing list