loop: better align order-of-events behavior between platforms

[vtjnash]

Previously, Windows would always defer event processing to the loop
after they were received. This could cause confusion for users who were
using prepare and idle callbacks, as seen from this bug in nodejs¹ and
this discussion in libuv², and even some discrepancies in the libuv
tests too³.

So rather than declare those usages to be wrong, we change libuv to meet
those users expectations.

Replaces: #3585

Footnotes

1. https://github.com/nodejs/node/pull/42340 ↩

2. https://github.com/libuv/libuv/discussions/3550 ↩

3. See change to test-spawn.c in this PR ↩

[vtjnash]

CI: https://ci.nodejs.org/view/libuv/job/libuv-test-commit/2246/
CI+node: https://ci.nodejs.org/view/libuv/job/libuv-in-node/211/

[bnoordhuis]

This patch should hopefully fix the node build errors:

diff --git a/deps/uv/uv.gyp b/deps/uv/uv.gyp
index 093f611fb6f..a3e9819a7e0 100644
--- a/deps/uv/uv.gyp
+++ b/deps/uv/uv.gyp
@@ -78,6 +78,8 @@
         'src/random.c',
         'src/strscpy.c',
         'src/strscpy.h',
+        'src/strtok.c',
+        'src/strtok.h',
         'src/threadpool.c',
         'src/timer.c',
         'src/uv-data-getter-setters.c',

[bnoordhuis]

https://ci.nodejs.org/view/libuv/job/libuv-in-node/212/ - this PR with gyp patch applied

[bnoordhuis]

The shared library build timed out (not our fault) and the osx-arm failure is known flake nodejs/node#42741 but the Windows failures might be related.

[vtjnash]

test.parallel/test-http-client-abort-unix-socket timeout

this seems somewhat concerning and needs to be investigated

test.async-hooks/test-tcpwrap Error Detailsfail (1) Stack Tracenode:assert:399 throw err; ^ AssertionError [ERR_ASSERTION]: Checking invocations at stage "tcpserver when server is closed": Never called "destroy", but expected 1 invocation(s). at checkHook (C:\workspace\node-test-binary-windows-js-suites\node\test\async-hooks\hook-checks.js:45:7) at Array.forEach () at checkInvocations (C:\workspace\node-test-binary-windows-js-suites\node\test\async-hooks\hook-checks.js:28:62) at Server.onserverClosed (C:\workspace\node-test-binary-windows-js-suites\node\test\async-hooks\test-tcpwrap.js:131:3) at Server.onserverClosed (C:\workspace\node-test-binary-windows-js-suites\node\test\common\index.js:438:15) at Object.onceWrapper (node:events:641:28) at Server.emit (node:events:527:28) at emitCloseNT (node:net:1736:8) at process.processTicksAndRejections (node:internal/process/task_queues:81:21) { generatedMessage: false, code: 'ERR_ASSERTION', actual: false, expected: true, operator: '==' } Node.js v19.0.0-pre

From a quick glance, this looks like it might be calling the 'destroy' handle with a setImmediate callback, and somehow the timing of that is changing here. I am not sure yet whether that is a bad assumption with nodejs or an issue being caused here.

The rest look likely to be nodejs bugs (some already known and in the process of being fixed).

test.pummel/test-regress-GH-892

This looks fairly suspect, since it seems that the client code is doing a big upload, then is depending on res.resume() to keep the loop alive after that finishes and gets EOF, while the server code expects to get EOF then write a final message to the socket. This seems incompatible with the normal nodejs behavior of destroying the stream (halfOpen: false) as soon as it sees EOF. Particularly also for TLS, which used to mandate the stream be destroyed in this case (v1.2 and earlier). That part of the standard was fixed in v1.3, but nodejs still mostly follows the old behavior specified there in my past observations.

[vtjnash]

The TCPWRAP failure seems related to nodejs/node#17117, which appears to define that uv_check_t handles must be run in some particular way and order relative to some other events, such that the callback from that immediate_check_handle_ in async_wrap gets dispatched prior to the onserverClosed event getting called from the close handler. I am still not sure what is causing that to change though. @addaleax seems to be the original author there?