Get a pair of sockets connected, e.g.:

accept := Socket newTCP listenOn: 12345 backlogSize: 5.
[ client := Socket newTCP connectTo: NetNameResolver localHostAddress port: 12345 ] fork.
server := accept waitForConnectionFor: 1; accept.

Then try to send a message that is too large to fit in any of the various send buffers, and don't do anything on the other end:

server sendData: (ByteArray new: 10**6 withAll: 37).

I expect this to block for, in this case, 60s, then raise an error. Instead, it hot-spins—sendDone always returns true, so it tries sending, which fails with EWOULDBLOCK (as expected), which gets converted to a return value of 0 from sendSomeData:..., and around and around we go, with Pharo consuming 100% CPU.

This behavior is definitely new since VM version 10.0.5. Looks to me like it comes from the EPOLL implementation added in May/June 2024, see 1eeb107. I don't fully understand what's going on—what is the "event system" the comments refer to? Seems like maybe something got half-done and the rest needs to be hooked up?