Socketpair blocking behavior depends on send buffer size

[codypiersall]

Windows version: Microsoft Windows [Version 10.0.17763.292] (Opted in to the October 2018 update)

While looking in to python-trio/trio#893, I discovered that WSL is still acting kinda weird with nonblocking behavior. It seems that non-blocking behavior is dependent on the size of the send buffer. The following code blocks forever, but shouldn't. This is exactly the same code from #3100, but with a tweak to the buffer size.

#include <sys/socket.h>
#include <sys/types.h>
#include <fcntl.h>
#include <stdio.h>
#include <errno.h>
#include <string.h>
#include <unistd.h>

int reportError(const char* syscall, int ec) {
  printf("%s: %s\n", syscall, strerror(ec));
  return 1;
}

int main(int argc, const char* argv[]) {
  int sv[2];
  int typeMask = 0;
  int flags = 0;

  if (argc == 2 && strcmp(argv[1], "-f") == 0) {
    flags |= O_NONBLOCK;
  } else {
    typeMask |= SOCK_NONBLOCK;
  }

  if (socketpair(PF_LOCAL, SOCK_STREAM | typeMask, 0, sv) < 0)
    return reportError("socketpair", errno);

  if (flags) {
    if (fcntl(sv[0], F_SETFL, flags) < 0)
      return reportError("fcntl", errno);
    if (fcntl(sv[1], F_SETFL, flags) < 0)
      return reportError("fcntl", errno);
  }

  static const char buf[163840] = {0};
  for (;;) {
    int rv = write(sv[0], buf, sizeof(buf));
    if (rv < 0) {
      reportError("write", errno);
      break;
    }
  }
  close(sv[0]);
  close(sv[1]);
  return 0;
}

In my testing, any buffer size less than 10 * 2**14 respected the nonblocking flag, but any larger buffer did not.

[craigloewen-msft]

Thank you for showing us this behavior! I was able to repro this problem and I'll mark it as bug so we can take a look into it.

[microsoft-github-policy-service]

This issue has been automatically closed since it has not had any activity for the past year. If you're still experiencing this issue please re-file this as a new issue or feature request.

Thank you!