Use posix_spawn to start the Bazel server.
Introduce a new "daemonize" helper tool that takes the heavy-lifting
of starting the Bazel server process as a daemon. This tool is pure
C and does not have any big dependencies like gRPC so we can ensure
it's thread-free. As a result, the code in this tool doesn't have
to take a lot of care when running fork(), which results in easier
to read code overall.
Then, change the Bazel client to simply use posix_spawn to invoke
this helper tool, which in turn runs the Bazel server as a daemon.
The code in the Bazel client becomes simpler as well as we don't
have to worry about the implications of using fork() from a threaded
process.
The switch to posix_spawn is necessary to address
https://github.com/bazelbuild/bazel/issues/7446 because the only way
to customize the QoS of a process in macOS is by using this API.
Such a change will come separately.
This change is intended to be a no-op. However, this fixes a bug
introduced in unknown commit by which we violated the requirement of
not doing any memory management from a child process started with
fork(). (I don't think this bug ever manifested itself, but it was
there -- which is funny because this piece of code went to great
extents to not do the wrong thing... and a one-line change let
hell break loose.)
RELNOTES: None.
PiperOrigin-RevId: 234991943
diff --git a/src/BUILD b/src/BUILD
index e7fd73a..82c5f13 100644
--- a/src/BUILD
+++ b/src/BUILD
@@ -358,7 +358,12 @@
"//src/main/tools:jdk-support",
"//src/main/tools:linux-sandbox",
"//tools/osx:xcode-locator",
- ],
+ ] + select({
+ "//src/conditions:windows": [],
+ "//conditions:default": [
+ "//src/main/tools:daemonize",
+ ],
+ }),
outs = ["package" + suffix + ".zip"],
cmd = "$(location :package-bazel.sh) $@ " + ("" if embed else "''") + " $(SRCS)",
tools = ["package-bazel.sh"],
