deps: upgrade libuv to 1.9.0

[saghul]

Pull Request check-list

Please make sure to review and check all of these items:

• Does make -j8 test (UNIX) or vcbuild test nosign (Windows) pass with
  this change (including linting)?
• Is the commit message formatted according to CONTRIBUTING.md?
• If this change fixes a bug (or a performance problem), is a regression
  test (or a benchmark) included?
• Is a documentation update included (if this change modifies
  existing APIs, or introduces new ones)?

NOTE: these things are not required to open a PR and can be done
afterwards / while the PR is open.

Affected core subsystem(s)

deps / libuv

Description of change

WIP, just to get the ball rolling. The release is near, so better run this through the CI to see there are no problems (running tests locally on OSX yields good hope).

I referenced all Node issues I could find, if you know of any others please let me know!

Fixes: #5737
Fixes: #4643
Fixes: #4291
Fixes: nodejs/node-v0.x-archive#8960

[cjihrig]

Rubber stamp LGTM. CI: https://ci.nodejs.org/job/node-test-pull-request/2118/

[cjihrig]

CI is all 💚

[saghul]

Sweet! Let's give it a couple more days to see if we can land those 2 items in libuv and make an actual release!

[Fishrock123]

I think this also allows #3594 to work?

[jasnell]

Woohoo! rubber stamp LGTM

[Trott]

@saghul There's nothing in 1.9.0 that will help with #954 by any chance, is there? (Doesn't look like it to me, but I can be less-than-perceptive on these sorts of things...)

[saghul]

I'm afraid not. I tried to reproduce the original problem a while ago,
without success.
On Apr 1, 2016 18:21, "Rich Trott" notifications@github.com wrote:

@saghul https://github.com/saghul There's nothing in 1.9.0 that will
help with #954 #954 by any chance,
is there? (Doesn't look like it to me, but I can be less-than-perceptive on
these sorts of things...)

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#5994 (comment)

[saghul]

It does, I'll mention it in the commit message.
On Apr 1, 2016 11:55, "Jeremiah Senkpiel" notifications@github.com wrote:

I think this also allows #3594 #3594
to work?

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
#5994 (comment)

[mscdex]

Any update on the timeline for the release?

[cjihrig]

@mscdex see libuv/libuv#778 (comment)

[saghul]

libuv 1.9.0 is out and about. I added the extra changes here.

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

[saghul]

Ups, make that https://ci.nodejs.org/job/node-test-pull-request/2194/

[bnoordhuis]

Forgot about CERTIFY_SAFE? :-) Rubber-stamp LGTM.

[cjihrig]

Still LGTM

[jbergstroem]

LGTM. Fail look unrelated.

[saghul]

Thanks everyone for the reviews! Landed! 🎉

[cjihrig]

If you can do it fast enough, you might want to force push and add Reviewed-By metadata.

[saghul]

F*ck, I added it, but I guess I managed to delete it :-( Will fix.

[saghul]

Force pushed. Thanks for noticing Colin! I'm not sure what happened there 😢

[cjihrig]

Thanks for fixing so quickly.

[MylesBorins]

@saghul exactly what @jasnell said. While fixing the bugs is a top priority... those bugs have existed for a bit and people to some extent expect them. The breakages that have been reported are new, and workflow breaking. I felt uncomfortable putting this on 5 knowing that we would be shipping workflow breaking changes, especially since this is going to be included in 6 next week.

[kzc]

While fixing the bugs is a top priority... those bugs have existed for a bit and people to some extent expect them.

I disagree with this statement. A bug is a bug. Just because older bugs weren't addressed in a timely fashion does not mean they are less important.

As for process.exit not flushing stdout and stderr, this has always been problematic throughout node's existence. Although the node 4.x and 5.x series happened to flush stdout for david upon process.exit there is no guarantee it works in the general case.

[jasnell]

@kzc ... it's not that the bugs aren't important.. it's definitely important to fix them! It's just that we need to be a bit cautious about pulling the libuv update into v4 until we can make sure that there are no additional unforeseen impacts. That's not to say we'll never pull it back, just that we may need to give it a few weeks while we, and the ecosystem, get things tested.

[kzc]

@jasnell Do you acknowledge that the behavior of flushing stdout/stderr upon process.exit has always been and remains undefined?

[MylesBorins]

@kzc, perhaps I didn't do a good job of expressing my intentions

v5 is end of life. There are not going to be many more releases of it. v6 is being released on Tuesday.

This patch will land in v6 on tuesday. What I have opted to do is not land it on v5 as we don't know yet exactly what effect this will have on the ecosystem. This will leave v5 in a state similar to where it already is, and allow the regressions to be found in v6.

Once we have an idea of exactly what regressions there are, and assuming those regressions are not going to cause a serious problem, this will be able to be backported to v4.

What I want to avoid is having to cut multiple v5's, or potentially leaving v5 in a less stable state by landing this upgrade.

[saghul]

@thealphanerd I wasn't aware of 5 being EOL, 👍 then!

[MylesBorins]

There will still be a couple updates, but the idea is that it is winding down. Below you can see the current LTS schedule

[jasnell]

It's EOL_-ish_. It's likely to still have a bit more life in it over the next month or two, it's just not the priority once v6 comes out.

[kzc]

@mgol reported that another process.exit() issue came to light in a popular third party app. The process.exit issue is likely quite common with node command line apps. Should hold off on merging libuv 1.9.0 into node 6 release in its present state.