Pipe does not exist error 121

PROBLEM DEFINITION

 Under normal usage the code as written can cause livelock, where the CPU usage goes to 50% or higher per outstanding connection request — I have observed usage rates approaching 100%, depending on how many simultaneous connection attempts were in progress.

 The snippet shown here is the relevant portion of the code in System.IO.Pipes (from Reflector).

 public void Connect(int timeout)
{
    // … other code here
    int startTickCount = Environment.TickCount;
    int elapsed = 0;
    while ((timeout == -1) || ((elapsed = Environment.TickCount — startTickCount) < timeout))
    {
      if ( !UnsafeNativeMethods.WaitNamedPipe(this.m_normalizedPipePath, timeout — elapsed) )
      {
          int errorCode = Marshal.GetLastWin32Error();
          if (errorCode == 2 ) // pipe does not exist
            continue;
          else if (errorCode == 0 ) // timeout occurred in WaitNamedPipe
            break; // done
          __Error.WinIOError(errorCode, string.Empty);
      }
      //… other code here…
      return;
    }
  throw new TimeoutException();
}

 CODE ANALYSIS

The source of the problem is the call to WaitNamedPipe(). The Win32 docuemntation states that it returns when an instance of the pipe becomes available or a timoeut occurs. However, the remarks section have an additional comment: «If no instances of the specified pipe exist, the WaitNamedPipe function returns immediately, regardless of time-out value.»

 In other words, if a named pipe instance exists and a client attempts to connect, the method will wait until either the server accepts the connection request or it times out, so that a timeout will occur only if the server takes too long to wake up and accept the connection — this is the expected behavior.

But when the pipe does not exist at all WaitNamedPipe does not wait, it just returns immediately with an error code; perhaps the server has not started yet, or is not at a point where it can create a pipe.

 When this occurs, the NamedPipeClientStream.Connect code goes into a tight loop that spins around calls to WaitNamedPipe; it continually polls WaitNamedPipe until the elapsed time exceeds the timeout value and the method throws a timeout exception; or if the timeout is specified as -1, it will spin until the process exits or the thread is aborted. This causes livelock/CPU hang.

 The developer who wrote this obviously knew this could occur since the code explicitly handles that case, but it was not documented that it could behave this way.

SOLUTIONS?

 So, as to workarounds and other issues….

This might only work when the named pipe is on the same machine as the client, but since that’s my use case it’s the one I am most interested in.

 Does anyone have any advice here?

First, use an algorithm that does not cause livelock.

Second, if the pipe does not exist then return immediately with a suitable error code, or an exception, that makes it obvious what the problem is. This is a different case then the server existing but not responding in a timely manner.

Third, an option for returning a value of false when it times out rather than throw an exception, and return true if it succeeds. Timeouts here are not necessarily errors and should not throw exceptions.