This is an archive of the discontinued LLVM Phabricator instance.

[clangd] Shutdown sequence for modules, and doc threading requirements
ClosedPublic

Authored by sammccall on Feb 16 2021, 12:16 AM.

Details

Summary

This allows modules to do work on non-TUScheduler background threads.

Diff Detail

Event Timeline

sammccall created this revision.Feb 16 2021, 12:16 AM
sammccall requested review of this revision.Feb 16 2021, 12:16 AM
kadircet added inline comments.Feb 16 2021, 12:49 AM
clang-tools-extra/clangd/ClangdServer.cpp
190

why is our contract saying that just calling stop is not enough?
i think clangdserver should just signal shutdown to modules, and our contract should say that server facilities will be undefined from this point forward.
that way modules accessing the facilities, could block stop until they are done, and never make use of it afterwards? it'll make modules a little more complicated, at the very least they would need some stricter control whenever they are accessing facilities, but I think it is worth for keeping clangdserver shutdown cleaner. wdyt?

clang-tools-extra/clangd/unittests/ClangdLSPServerTests.cpp
273

= false;

361

not sure what this is testing in addition to final callback receiving 3 as a value.

sammccall updated this revision to Diff 324120.Feb 16 2021, 3:04 PM
sammccall marked 2 inline comments as done.

trim tests

clang-tools-extra/clangd/ClangdServer.cpp
190

We need Module::blockUntilIdle anyway for tests and stuff. And in practice requesting shutdown of background work doesn't naturally block until that work is complete IME.

So we could ask every module to call blockUntilIdle() in stop(), or make stop() non-virtual and have it wrap requestStop()+blockUntilIdle().

Neither really seems simpler/cleaner to me overall, and it means modules shut down in serial instead of parallel.

kadircet accepted this revision.Feb 17 2021, 12:17 AM

thanks, lgtm!

clang-tools-extra/clangd/ClangdServer.cpp
190

We need Module::blockUntilIdle anyway for tests and stuff

i was trying to ensure it is *only* used for tests, but i suppose you are right, in practice making stop block until in-flight tasks finishes vs stop+blockuntilidle is likely to have same effect, with the latter having the benefit of triggering shut down in parallel. so SGTM.

This revision is now accepted and ready to land.Feb 17 2021, 12:17 AM
sammccall updated this revision to Diff 324262.Feb 17 2021, 3:53 AM

Fix racy test - forgot to blockUntilIdle in sync!

Found a bug in blockUntilIdle, i'll send it separately.