I'm working on a project on MacOS that makes RPC calls using the Rust bitcoincore-rpc crate, against the bitcoind prebuilt binary available here.

Some RPC calls succeed, but some fail with this error:

Error: Rpc(JsonRpc(Transport(SocketError(Os { code: 35, kind: WouldBlock, message: "Resource temporarily unavailable" }))))

After much debugging, we found that when we used the version of bitcoind provided by homebrew, the exact same sequence of RPC calls would succeed. We were able to reproduce this on both an x86 mac and an ARM mac.

We haven't been able to figure out what the disparity is, but looking at the homebrew bitcoind formula defiinition might provide some clues.

In particular:

  def install
    system "./autogen.sh"
    system "./configure", *std_configure_args,
                          "--disable-dependency-tracking",
                          "--disable-silent-rules",
                          "--with-boost-libdir=#{Formula["boost@1.76"].opt_lib}"
    system "make", "install"
    pkgshare.install "share/rpcauth"
  end

It looks like homebrew is passing additional arguments to configure, std_configure_args, and is using a version of boost built by homebrew. I tried using brew install -s boost@1.76 bitcoind, to see if this also produced a binary that worked, and it did. The logs from that build are available here.

I've run into similar problems like this one a few times before, i.e., RPC calls to bitcoind failing on MacOS due to inscrutable I/O errors. One time, I was able to fix it by increasing the open file limit using ulimit -n BIG_NUMBER, but that doesn't seem to work here.

My best guess is that the homebrew poeople have gotten pretty good at configuring packages on MacOS, and they're passing some flag, or using a patched version of boost, or linking it differently, such that the binary they produce isn't affected by this issue.