1 files changed, 4 insertions, 22 deletions
diff --git a/src/tools/remote/src/main/java/com/google/devtools/build/remote/worker/ExecutionServer.java b/src/tools/remote/src/main/java/com/google/devtools/build/remote/worker/ExecutionServer.java
index f9506987f6..19556dc9bd 100644
--- a/src/tools/remote/src/main/java/com/google/devtools/build/remote/worker/ExecutionServer.java
+++ b/src/tools/remote/src/main/java/com/google/devtools/build/remote/worker/ExecutionServer.java
@@ -76,7 +76,6 @@ import java.util.logging.Logger;
 final class ExecutionServer extends ExecutionImplBase {
   private static final Logger logger = Logger.getLogger(ExecutionServer.class.getName());
 
-  private final Object lock = new Object();
 
   // The name of the container image entry in the Platform proto
   // (see third_party/googleapis/devtools/remoteexecution/*/remote_execution.proto and
@@ -215,27 +214,10 @@ final class ExecutionServer extends ExecutionImplBase {
     CommandResult cmdResult = null;
 
     FutureCommandResult futureCmdResult = null;
-    synchronized (lock) {
-      // Linux does not provide a safe API for a multi-threaded program to fork a subprocess.
-      // Consider the case where two threads both write an executable file and then try to execute
-      // it. It can happen that the first thread writes its executable file, with the file
-      // descriptor still being open when the second thread forks, with the fork inheriting a copy
-      // of the file descriptor. Then the first thread closes the original file descriptor, and
-      // proceeds to execute the file. At that point Linux sees an open file descriptor to the file
-      // and returns ETXTBSY (Text file busy) as an error. This race is inherent in the fork / exec
-      // duality, with fork always inheriting a copy of the file descriptor table; if there was a
-      // way to fork without copying the entire file descriptor table (e.g., only copy specific
-      // entries), we could avoid this race.
-      //
-      // I was able to reproduce this problem reliably by running significantly more threads than
-      // there are CPU cores on my workstation - the more threads the more likely it happens.
-      //
-      // As a workaround, we put a synchronized block around the fork.
-      try {
-        futureCmdResult = cmd.executeAsync();
-      } catch (CommandException e) {
-        Throwables.throwIfInstanceOf(e.getCause(), IOException.class);
-      }
+    try {
+      futureCmdResult = cmd.executeAsync();
+    } catch (CommandException e) {
+      Throwables.throwIfInstanceOf(e.getCause(), IOException.class);
     }
 
     if (futureCmdResult != null) {