PollRegistrations sometimes misses a readable socket with kqueue on macOS arm64 #431

The PollRegistrations regression test (from #320, e52079d) fails now and then on macOS arm64. It has failed in 2 of the last 5 runs with Haxe 5.0.0-preview.1, and in none of the 5 with Haxe 4.3.7. Linux (epoll) and Windows (select) have not failed it.

• https://github.com/openfl/libhxcpp/actions/runs/42103594769/job/127514337771 (cca54f5)
• https://github.com/openfl/libhxcpp/actions/runs/42225372186/job/127918850097 (6ac0324)

Both fail the same two checks:

one socket both ways, readable: false
one socket twice: false

  got [] [0], expected [0] [0]
  got [] [0], expected [0,2] [0]

The client of a loopback TCP pair is prepared for writing alone, then for reading and writing, which adds EVFILT_READ to its registration. The idle check passes, so the read filter was registered: had the EV_ADD failed, the index would be reported ready on every call. The server then writes 5 bytes, and for the next second (50 waits of 20 ms) kevent reports the client writable but never readable. It still isn't readable after the next prepare, which takes the write filter off and registers the server. The blocking readString(5) that follows does get the bytes, so they arrived at some point.

So either kqueue doesn't deliver the read event for a socket whose write filter was registered first, or the bytes take more than a second to show up on loopback. Neither has been reproduced off CI. The Haxe 5 std's sys.net.Socket is the same as Haxe 4.3.7's for these calls, so the Haxe version may only be changing the timing.

Next

Run the test in a loop on a macOS arm64 machine, log each kevent result and the bytes the client's socket holds (FIONREAD) at each wait, and fix the cause.