From a9c46e5907be66248b6218ae70e0a1d999c696d5 Mon Sep 17 00:00:00 2001 From: lberki Date: Tue, 10 Oct 2017 18:29:56 +0200 Subject: [PATCH] Automated rollback of commit 61977f4ae57c877fc28be176f36c28642b276eec. *** Reason for rollback *** Breaks a test of Bazel on Windows: http://ci.bazel.io/view/Dashboard/job/bazel-tests/1078/testReport/src_test_py_bazel_bazel_clean_test/exe/src_test_py_bazel_bazel_clean_test_exe/ Fixes #3882. *** Original change description *** Don't release the client lock while the server executes a command. The server still doesn't support concurrency, even for commands like 'help', so there's no benefit from releasing it. This also improves progress messages. Today the client may print WARNING: Running Blaze server needs to be killed, because the startup options are different. and then wait indefinitely while the server finishes processing a request. With this change, an explanation for the delay is given. RELNOTES: None. GO... *** RELNOTES: None. PiperOrigin-RevId: 171689429 --- src/main/cpp/blaze.cc | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/src/main/cpp/blaze.cc b/src/main/cpp/blaze.cc index 96d8e56ccb4551..32b21a12e3ccad 100644 --- a/src/main/cpp/blaze.cc +++ b/src/main/cpp/blaze.cc @@ -1670,6 +1670,11 @@ unsigned int GrpcBlazeServer::Communicate() { std::unique_ptr> reader( client_->Run(&context, request)); + // Release the server lock because the gRPC handles concurrent clients just + // fine. Note that this may result in two "waiting for other client" messages + // (one during server startup and one emitted by the server) + blaze::ReleaseLock(&blaze_lock_); + std::thread cancel_thread(&GrpcBlazeServer::CancelThread, this); bool command_id_set = false; bool pipe_broken = false;