unix: refactor uv_try_write #2874

twose · 2020-06-05T10:29:00Z

the previous implementation was uv_write + uv_cancel, it's too hack

If this pr is acceptable, I hope we can implement uv_try_write2 and it always returns UV_EAGAIN when send_handle != NULL on WIN

ping @bnoordhuis

twose · 2020-06-10T08:20:01Z

This is just an optimization, it didn't break anything, it just decoupled the part of the system call from uv__write, I believe that it's more readable and performance now.
I am actively using the develop version of libuv so I hope to get some response, thank you

bnoordhuis

Thanks, this is indeed a nice improvement.

src/unix/stream.c

bnoordhuis

Thanks, LGTM.

CI: https://ci.nodejs.org/job/libuv-test-commit/1935/
Libuv+Node.js CI: https://ci.nodejs.org/view/libuv/job/libuv-in-node/136/

src/unix/stream.c

bnoordhuis · 2020-06-16T09:50:06Z

Libuv+Node.js CI again: https://ci.nodejs.org/view/libuv/job/libuv-in-node/137/

I'm pretty sure the failures in the previous run were caused by a flaky test and not this PR but better safe than sorry.

stale · 2020-07-07T15:49:14Z

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

vtjnash

Looks great to me also, but build logs are gone, so I can't know what CI issue you saw.

src/unix/stream.c

PR-URL: libuv#2874 Reviewed-By: Ben Noordhuis <[email protected]> Reviewed-By: Jameson Nash <[email protected]>

vtjnash · 2020-08-04T16:30:00Z

CI: https://ci.nodejs.org/job/libuv-test-commit/1975/
Libuv+Node.js CI: https://ci.nodejs.org/view/libuv/job/libuv-in-node/142/

vtjnash · 2020-08-04T18:40:02Z

Hm, that did surprisingly badly. Let's check that again: https://ci.nodejs.org/view/libuv/job/libuv-in-node/144/

vtjnash

CI has me concerned there's something wrong with this, though it's only failing one test

twose · 2020-08-05T09:24:37Z

@vtjnash
I cannot find the error message for the test, can you point it out for me? I am not very familiar with it, thanks.

vtjnash · 2020-08-05T13:52:46Z

There wasn't an error message, just a lot of instances of this test failing:

not ok 2315 parallel/test-tls-env-extra-ca
  ---
  duration_ms: 120.21
  severity: fail
  exitcode: -15
  stack: |-
    timeout
  ...

twose · 2020-08-07T07:38:07Z

Is this a nodejs test?
I don't know much about nodejs...
I need help @bnoordhuis
Please take a look at this if you have time...

bnoordhuis · 2020-08-09T11:27:02Z

@twose Yes, it's a node.js test. It's almost certainly a flake but let's try it one more time. Can you rebase against v1.x? Thanks.

twose · 2020-08-12T18:00:57Z

Recently some busy, sorry for being late, I've updated this :)

vtjnash · 2020-08-12T18:52:58Z

It failed quite a substantial number of times across many platforms (vs. no failures when I ran with the head of v1.x). I'm hoping nodejs CI isn't really that flaky, so I'm assuming it must be somehow related. Unfortunately, the old build logs are gone, so I'm not sure how to solve this. 😬

Attempted Nodejs+libuv CI: https://ci.nodejs.org/view/libuv/job/libuv-in-node/151/
Seems to be hitting a memory limit or memory corruption on a couple nodes now (so a different error than last week)?

cjihrig · 2020-08-12T18:58:59Z

The Node integration CI won't pass until nodejs/node#34751 or a similar change lands in Node.

twose · 2020-08-24T10:08:33Z

Friendly reminder :)
Can we try again now?

vtjnash · 2020-08-25T16:14:37Z

Here you go: https://ci.nodejs.org/view/libuv/job/libuv-in-node/163/

vtjnash · 2020-08-25T17:12:40Z

Still appears to show a sharply increased failure rate of that test: https://ci.nodejs.org/view/libuv/job/libuv-in-node/163/

twose · 2020-08-27T09:32:37Z

I reviewed the code again, but I still can not find any problems, the logic should be equivalent to the original.
and what is the meaning of "flaky"? I can not get it 😢 (maybe because of my poor English)

puzpuzpuz · 2020-09-09T12:29:21Z

and what is the meaning of "flaky"? I can not get it (maybe because of my poor English)

@twose a "flaky" test means a test that fails occasionally, under certain conditions, i.e. it does not always fail. Such tests are harmful, as they reduce the overall value of the test suite. Hopefully, the explanation is good enough.

twose · 2020-09-09T17:33:14Z

@puzpuzpuz I really appreciate your help and I got it.

I rebased it again. Hoping someone can help push forward the progress...

stale · 2020-10-19T16:25:01Z

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

stale · 2020-11-11T00:43:51Z

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

twose · 2020-11-17T02:48:38Z

@bnoordhuis need your help 🤯

vtjnash · 2020-11-17T04:58:37Z

I took a quick look, and it is indirectly related to this PR, though nodejs seems probably most at fault. It is timing related, and happens more often when the server is busy (e.g. running tests/parallel, then when it is idle). It's easy to reproduce under rr (record-and-replay). It seems perhaps related to #3006, as what I see is that nodejs calls uv_shutdown (in response to close_notify), then tries to do more uv_write calls, and forgets to ever call uv_close. It's also possibly thus related to nodejs/node#36111, as it hits precisely that issue also (the TLSWrap object gets UV_EOF, but knows it's already reported eof_ to the caller, and thus assumes the caller should have already schedule destroy and doesn't duplicate the notification)

vtjnash

Since, after analysis, I think the CI failure appears to be a race condition that needs to be fixed in nodejs, I'm proposing merging this. It should have no external functional changes, but makes the code cleaner and should avoid many syscalls.

stale · 2020-12-08T11:15:49Z

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

winterland1989 · 2021-02-19T13:27:05Z

Really want see this get merged in next release, could save lots of system call in some binding code.

stale · 2021-03-20T00:35:51Z

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

winterland1989 · 2021-03-20T01:26:38Z

Oh please don't, we desperately need this.

vtjnash · 2021-03-20T04:40:37Z

I won't let stalebot steal this: I plan to include it in the next release.

twose · 2021-05-12T02:38:56Z

Finally merged, thank you for all your assistance.

This simplifies the code, for better clarify (and performance)! PR-URL: libuv#2874 Reviewed-By: Jameson Nash <[email protected]>

This simplifies the code, for better clarify (and performance)! PR-URL: libuv/libuv#2874 Reviewed-By: Jameson Nash <[email protected]>

bnoordhuis reviewed Jun 12, 2020

View reviewed changes

src/unix/stream.c Outdated Show resolved Hide resolved

src/unix/stream.c Outdated Show resolved Hide resolved

src/unix/stream.c Outdated Show resolved Hide resolved

twose commented Jun 12, 2020

View reviewed changes

src/unix/stream.c Show resolved Hide resolved

bnoordhuis approved these changes Jun 13, 2020

View reviewed changes

src/unix/stream.c Outdated Show resolved Hide resolved

src/unix/stream.c Show resolved Hide resolved

stale bot added the stale label Jul 7, 2020

vtjnash approved these changes Jul 29, 2020

View reviewed changes

stale bot removed the stale label Jul 29, 2020

vtjnash reviewed Jul 29, 2020

View reviewed changes

src/unix/stream.c Outdated Show resolved Hide resolved

vtjnash force-pushed the uv_try_write branch from 7c38ba9 to e06f5e9 Compare August 4, 2020 16:28

vtjnash pushed a commit to twose/libuv that referenced this pull request Aug 4, 2020

unix,stream: refactor uv_try_write [NFCI]

e06f5e9

PR-URL: libuv#2874 Reviewed-By: Ben Noordhuis <[email protected]> Reviewed-By: Jameson Nash <[email protected]>

vtjnash requested changes Aug 4, 2020

View reviewed changes

twose force-pushed the uv_try_write branch from e06f5e9 to 7391562 Compare August 12, 2020 17:58

twose force-pushed the uv_try_write branch from 7391562 to b2c64fd Compare September 9, 2020 17:29

twose requested review from bnoordhuis and vtjnash September 28, 2020 10:00

stale bot added the stale label Oct 19, 2020

unix: refactor uv_try_write

839118b

twose force-pushed the uv_try_write branch from b2c64fd to 839118b Compare October 20, 2020 09:14

stale bot removed the stale label Oct 20, 2020

stale bot added the stale label Nov 11, 2020

stale bot removed the stale label Nov 17, 2020

vtjnash approved these changes Nov 17, 2020

View reviewed changes

stale bot added the stale label Dec 8, 2020

vtjnash mentioned this pull request Jan 6, 2021

Release proposal: v1.41.0 #3086

Closed

stale bot removed the stale label Feb 19, 2021

stale bot added the stale label Mar 20, 2021

stale bot removed the stale label Mar 20, 2021

vtjnash merged commit 23bebf0 into libuv:v1.x May 10, 2021

twose deleted the uv_try_write branch May 12, 2021 02:38

JeffroMF pushed a commit to JeffroMF/libuv that referenced this pull request May 16, 2022

unix: refactor uv_try_write

f52e465

This simplifies the code, for better clarify (and performance)! PR-URL: libuv#2874 Reviewed-By: Jameson Nash <[email protected]>

liujinye-sys pushed a commit to open-vela/apps_system_libuv that referenced this pull request Jul 23, 2025

unix: refactor uv_try_write

7f358e4

This simplifies the code, for better clarify (and performance)! PR-URL: libuv/libuv#2874 Reviewed-By: Jameson Nash <[email protected]>

liujinye-sys pushed a commit to open-vela/apps_system_libuv that referenced this pull request Dec 16, 2025

unix: refactor uv_try_write

80cbe59

This simplifies the code, for better clarify (and performance)! PR-URL: libuv/libuv#2874 Reviewed-By: Jameson Nash <[email protected]>

unix: refactor uv_try_write #2874

unix: refactor uv_try_write #2874

Uh oh!

Conversation

twose commented Jun 5, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

twose commented Jun 10, 2020

Uh oh!

bnoordhuis left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

bnoordhuis left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

bnoordhuis commented Jun 16, 2020

Uh oh!

stale bot commented Jul 7, 2020

Uh oh!

vtjnash left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

vtjnash commented Aug 4, 2020

Uh oh!

vtjnash commented Aug 4, 2020

Uh oh!

vtjnash left a comment

Choose a reason for hiding this comment

Uh oh!

twose commented Aug 5, 2020

Uh oh!

vtjnash commented Aug 5, 2020

Uh oh!

twose commented Aug 7, 2020

Uh oh!

bnoordhuis commented Aug 9, 2020

Uh oh!

twose commented Aug 12, 2020

Uh oh!

vtjnash commented Aug 12, 2020

Uh oh!

cjihrig commented Aug 12, 2020

Uh oh!

twose commented Aug 24, 2020

Uh oh!

vtjnash commented Aug 25, 2020

Uh oh!

vtjnash commented Aug 25, 2020

Uh oh!

twose commented Aug 27, 2020

Uh oh!

puzpuzpuz commented Sep 9, 2020

Uh oh!

twose commented Sep 9, 2020

Uh oh!

stale bot commented Oct 19, 2020

Uh oh!

stale bot commented Nov 11, 2020

Uh oh!

twose commented Nov 17, 2020

Uh oh!

vtjnash commented Nov 17, 2020

Uh oh!

vtjnash left a comment

Choose a reason for hiding this comment

Uh oh!

stale bot commented Dec 8, 2020

Uh oh!

winterland1989 commented Feb 19, 2021

Uh oh!

stale bot commented Mar 20, 2021

Uh oh!

winterland1989 commented Mar 20, 2021

twose commented Jun 5, 2020 •

edited

Loading