deps: upgrade to libuv 1.44.2

[lpinca]

Notable changes:

• Build regression fixes for various platform updates
  (bsd: ensure mutex is initialized libuv/libuv#3428,
  V1.x fix recvmmsg on musl libc libuv/libuv#3419,
  unix: don't allow too small thread stack size libuv/libuv#3423,
  darwin: translate EPROTOTYPE to ECONNRESET libuv/libuv#3413,
  build: rename CFLAGS to AM_CFLAGS libuv/libuv#3431)
• Support for GNU/Hurd (Unbreak build on GNU/Hurd libuv/libuv#3450)
• Release tool improvements
  (add autotools tarball support libuv/libuv-release-tool#13)
• Better performing rw locks on Win32 (The Windows SRWLock primitive can be used for rw locking instead of a custom CRITICAL_SECTION+Semaphore implementation #3382 libuv/libuv#3383)
• Support for posix_spawn API (posix spawn, take 2 libuv/libuv#3257)
• Fix regression on OpenBSD (process: remove OpenBSD from kevent list libuv/libuv#3506)
• Add uv_available_parallelism() (unix,win: add uv_available_parallelism() libuv/libuv#3499)
• Don't use thread-unsafe strtok() (macos: don't use thread-unsafe strtok() libuv/libuv#3524)
• Fix hang after NOTE_EXIT (process: fix hang after NOTE_EXIT libuv/libuv#3521)
• Better align order-of-events behavior between platforms
  (loop: better align order-of-events behavior between platforms libuv/libuv#3598)
• Fix fs event not fired if the watched file is moved/removed/recreated
  (zos: fix fs event not fired if the watched file is moved/removed/recreated libuv/libuv#3540)
• Fix pipe resource leak if closed during connect (and other bugs)
  (win: Fix pipe resource leak if closed during connect (and other bugs) libuv/libuv#3611)
• Don't error when killing a zombie process
  (zos: don't error when killing a zombie process libuv/libuv#3625)
• Avoid posix_spawnp() cwd bug (macos: avoid posix_spawnp() cwd bug libuv/libuv#3597)
• Skip EVFILT_PROC events when invalidating events for an fd
  (kqueue: skip EVFILT_PROC events when invalidating events for an fd. libuv/libuv#3629)

Fixes: #42290

[targos]

RSLGTM

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/43042/

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/43052/

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/43055/

[lpinca]

There seem to be some relevant test failures on Windows.

cc: @nodejs/platform-windows @nodejs/fs

[targos]

May be libuv/libuv#3193 ?
@RaisinTen

[lpinca]

We could fix the EPERM -> EACCES stuff in the tests but I think it would be semver-major.

Also, there are two other different failures on Windows that need to be investigated:

1. node/test/parallel/test-os.js

   Line 215 in d4d0b09

   assert.strictEqual(pwd.uid, -1);

   pwd.uid is 4294967295 instead of -1. The culprit here seems to be libuv/libuv@f3e0bff.

2. node/test/parallel/test-timers-immediate-unref-nested-once.js

   Line 8 in d4d0b09

   setImmediate(common.mustNotCall()).unref();

   The callback is called when it should not. The offending commit is libuv/libuv@939a056.

cc: @nodejs/libuv @vtjnash

[RaisinTen]

Yes, I can confirm that libuv/libuv#3193 caused the EPERM and EACCES mismatches and yes, this change should be labelled as semver-major because other modules like https://github.com/isaacs/rimraf also depends on the error code being EPERM instead of EACCES.

cc @isaacs

[richardlau]

Yes, I can confirm that libuv/libuv#3193 caused the EPERM and EACCES mismatches and yes, this change should be labelled as semver-major because other modules like https://github.com/isaacs/rimraf also depends on the error code being EPERM instead of EACCES.

This means we will be unable to update libuv in LTS to this or subsequent versions.

[lpinca]

This patch

diff --git a/deps/uv/src/win/core.c b/deps/uv/src/win/core.c
index c08dedc47c..cfd52e5148 100644
--- a/deps/uv/src/win/core.c
+++ b/deps/uv/src/win/core.c
@@ -401,7 +401,6 @@ int uv_loop_fork(uv_loop_t* loop) {
 static int uv__loop_alive(const uv_loop_t* loop) {
   return uv__has_active_handles(loop) ||
          uv__has_active_reqs(loop) ||
-         loop->pending_reqs_tail != NULL ||
          loop->endgame_handles != NULL;
 }

fixes the third issue (point 2 in my previous comment) but I'm not sure if it hides another issue/bug.

[RaisinTen]

This means we will be unable to update libuv in LTS to this or subsequent versions.

@richardlau is that something we are okay with or should we revert the change in the libuv repo?

[aduh95]

621ae7f could land on a separate PR, as it is not semver-major.

node/doc/contributing/collaborator-guide.md

Lines 513 to 514 in a199387

	All commits should be self-contained, meaning every commit should pass all
	tests. This makes it much easier when bisecting to find a breaking change.

We would need to either squash the commits when merging, or add a first commit that disables the test that the update break, or make an exception (see #42356 (comment)).

[richardlau]

This means we will be unable to update libuv in LTS to this or subsequent versions.

@richardlau is that something we are okay with or should we revert the change in the libuv repo?

On the one hand if we say "we'll never update libuv again in any of the existing LTS releases" then that's less work for releasers but I don't feel comfortable in making that statement. We could float patches but that's not particularly friendly to others who build their own packages of Node.js (Linux distros, homebrew etc) who dynamically link against a shared libuv library.

My question is, given the change would cause ecosystem breakage, is it worth it?

[lpinca]

621ae7f could land on a separate PR, as it is not semver-major.

It could, but it does not make sense without the libuv update.

[targos]

My question is, given the change would cause ecosystem breakage, is it worth it?

If it breaks things as popular as rimraf, I'd say it's not.