{"payload":{"header_redesign_enabled":false,"results":[{"body":"I had been meaning to look into doing this for some time, as noted in\nhttps://github.com/nodejs/node/pull/25638#pullrequestreview-195785677.\n\ntl;dr the only reason (so far as I could tell) that windows pipes are sync is that at the time they were made sync, unix\nwas also sync (for some reason that I don t recall).\n\n(They were made blocking in https://github.com/nodejs/node/commit/20176a98416353d4596900793f739d5ebf4f0ee1 as a response\nto https://github.com/nodejs/node-v0.x-archive/issues/3584.)\n\nAnyways I tried to do it with the following patch, but it caused more CI errors than I had expected, across all windows\nmachines, and I m not sure I am invested enough to deal with them so I ll leave them here in case anyone is interested.\n\ndetails summary (Patch to make windows pipes async again.) /summary\n\ndiff --git a/lib/net.js b/lib/net.js\nindex 9eb7448c59..6c70cae264 100644\n--- a/lib/net.js\n+++ b/lib/net.js\n@@ -283,23 +283,6 @@ function Socket(options) {\n       throw errnoException(err,  open );\n \n     this[async_id_symbol] = this._handle.getAsyncId();\n-\n-    if ((fd === 1 || fd === 2)   \n-        (this._handle instanceof Pipe)   \n-        process.platform ===  win32 ) {\n-      // Make stdout and stderr blocking on Windows\n-      err = this._handle.setBlocking(true);\n-      if (err)\n-        throw errnoException(err,  setBlocking );\n-\n-      this._writev = null;\n-      this._write = makeSyncWrite(fd);\n-      // makeSyncWrite adjusts this value like the original handle would, so\n-      // we need to let it do that by turning it into a writable, own property.\n-      Object.defineProperty(this._handle,  bytesWritten , {\n-        value: 0, writable: true\n-      });\n-    }\n   }\n \n   // shut down the socket when we re finished with it.\n\n/details\n\n...\n\ndetails\n\nsummary 46 Failures: /summary\n\ntest.parallel/test-child-process-stdout-flush-exit\ntest.parallel/test-cli-eval\ntest.parallel/test-module-main-fail\ntest.parallel/test-preload\ntest.parallel/test-module-main-fail\ntest.parallel/test-preload\ntest.parallel/test-worker-memory\ntest.parallel/test-debug-usage\ntest.parallel/test-module-main-preserve-symlinks-fail\ntest.parallel/test-stdio-pipe-redirect\ntest.parallel/test-stdout-close-catch\ntest.sequential/test-stream2-stderr-sync\ntest.parallel/test-child-process-stdout-flush-exit\ntest.parallel/test-debug-usage\ntest.parallel/test-module-main-preserve-symlinks-fail\ntest.parallel/test-stdio-pipe-redirect\ntest.sequential/test-stream2-stderr-sync\ntest.parallel/test-module-main-fail\ntest.parallel/test-preload\ntest.sequential/test-repl-timeout-throw\ntest.parallel/test-module-main-fail\ntest.parallel/test-preload\ntest.sequential/test-repl-timeout-throw\ntest.parallel/test-debugger-pid\ntest.parallel/test-child-process-stdout-flush-exit\ntest.parallel/test-cli-eval\ntest.parallel/test-debug-usage\ntest.parallel/test-module-main-preserve-symlinks-fail\ntest.sequential/test-stream2-stderr-sync\ntest.parallel/test-child-process-stdout-flush-exit\ntest.parallel/test-cli-eval\ntest.parallel/test-debug-usage\ntest.parallel/test-module-main-preserve-symlinks-fail\ntest.parallel/test-stdio-pipe-redirect\ntest.parallel/test-stdout-close-catch\ntest.sequential/test-stream2-stderr-sync\ntest.parallel/test-child-process-stdout-flush-exit\ntest.parallel/test-cli-eval\ntest.parallel/test-module-main-fail\ntest.parallel/test-preload\ntest.sequential/test-repl-timeout-throw\ntest.parallel/test-debug-usage\ntest.parallel/test-module-main-preserve-symlinks-fail\ntest.parallel/test-stdio-pipe-redirect\ntest.parallel/test-stdout-close-catch\ntest.sequential/test-stream2-stderr-sync\n\n/details\n\n...\n\nLink to the CI run while it lasts: https://ci.nodejs.org/job/node-test-commit-windows-fanned/24192/\n\nIt s possible there was some other reason that windows pipes were made sync or some other implication or side effect I\ndon t know about, but I m not invested enough to debug it.\n\nAnyways I made this issue if nothing else for posterity in case people are interested.\n","created":"2019-01-25T01:36:39.000Z","hl_text":"I had been meaning to look into doing this for some time, as noted in\nhttps://github.com/nodejs/node/pull/25638#pullrequestreview-195785677.\n\ntl;dr the only reason (so far as I could tell) that windows ...","hl_title":"Make windows stdio pipes async (?)","id":"24976","num_comments":7,"number":25691,"repo":{"repository":{"id":27193779,"name":"node","owner_id":9950313,"owner_login":"nodejs","updated_at":"2024-06-08T11:57:21.714Z","has_issues":true}},"title":"Make windows stdio pipes async (?)","url":"/nodejs/node/discussions/25691","updated":"2022-08-01T14:03:46.000Z","user_avatar_url":"https://avatars.githubusercontent.com/u/1093990?s=48&v=4","user_id":1093990,"user_login":"Fishrock123"},{"body":"The legacy url API (url.parse(), url.format(), and url.resolve()) have been docs-only deprecated.\n\nFollowing the Node.js 11.0.0 release, I plan to open a PR that upgrades that to a pending runtime-deprecation (requires\n--pending-deprecation for the warning to appear). That would land in master but would not go into a release until 12.0.0\n(April 2019)\n\nFollowing the 12.0.0 release, I plan to on a PR that upgrades that to a full run-time deprecation that would last in\nmaster but would not go into a release until 13.0.0 (October 2019).\n\nAfter the 13.0.0 release, I would like to move the legacy url API to End-of-Life, allowing us to remove it.\n\nTo support existing code that is still using the legacy URL, the implementation can be moved into a separate standalone\nmodule published on npm (similar to the existing node-url module).\n","created":"2018-10-16T16:19:03.000Z","hl_text":"The legacy url API (url.parse(), url.format(), and url.resolve()) have been docs-only deprecated.\n\nFollowing the Node.js 11.0.0 release, I plan to open a PR that upgrades that to a pending runtime-deprecation ...","hl_title":"Tracking Issue: Legacy URL deprecation","id":"24978","num_comments":16,"number":23694,"repo":{"repository":{"id":27193779,"name":"node","owner_id":9950313,"owner_login":"nodejs","updated_at":"2024-06-08T11:57:21.714Z","has_issues":true}},"title":"Tracking Issue: Legacy URL deprecation","url":"/nodejs/node/discussions/23694","updated":"2022-06-02T17:56:58.000Z","user_avatar_url":"https://avatars.githubusercontent.com/u/439929?s=48&v=4","user_id":439929,"user_login":"jasnell"},{"body":"Yarn has had its first major release [1], and I think it should be taken under serious consideration as a de-facto\nreplacement for NPM as the default package manager.\n\nYarn is compatible with NPM while being much more performant. It also supports a wide array of features and is under\nactive and rapid development. It has great traction in the community, with almost 200k repos on GitHub using it to some\nextent. Defaulting to it will likely be beneficial both to the community and the Node ecosystem at large.\n\n[1] https://code.facebook.com/posts/274518539716230\n","created":"2017-09-07T17:27:15.000Z","hl_text":"Yarn has had its first major release [1], and I think it should be taken under serious consideration as a de-facto\nreplacement for NPM as the default package manager.\n\nYarn is compatible with NPM while ...","hl_title":"[Feature] Discussion around default package manager choice","id":"24979","num_comments":106,"number":15244,"repo":{"repository":{"id":27193779,"name":"node","owner_id":9950313,"owner_login":"nodejs","updated_at":"2024-06-08T11:57:21.714Z","has_issues":true}},"title":"[Feature] Discussion around default package manager choice","url":"/nodejs/node/discussions/15244","updated":"2022-05-31T18:51:24.000Z","user_avatar_url":"https://avatars.githubusercontent.com/u/1127729?s=48&v=4","user_id":1127729,"user_login":"csvan"},{"body":"  - Version: All\n  - Platform: All\n  - Subsystem: domain\n\n!-- Enter your issue details below this comment. --\n\nHi all 👋\n\nThe meta-problem: Many core contributors have expressed a desire to get rid of domains. In order to get rid of domains,\nit s also been expressed that Node should provide migration routes for users. Domains provide two functions to users:\nthe ability to intercept uncaught exceptions for a subset of all JS execution, and (as a useful side-effect of the first\nfunction) the ability to associate multiple asynchronous continuations with a single JS object (available contextually\nper continuation at process.domain). It s this second function of domains that brings me to this issue!\n\nSince async hooks are now an official (if experimental) API, I took some time to explore moving pg-db-session from\ndomains to async hooks. pg-db-session uses the second function of domains — the ability to associate multiple\ncontinuations with a well-known object — to back continuation local storage. Specifically, we use this to associate all\ncontinuations associated with a particular HTTP request to a postgres session. (An aside: this has been in production\nhas worked swimmingly for the last year and a half, with no memory leaks. At the time the library was written,\nAsyncHooks weren t quite sufficient for our needs.)\n\nThe problem: In moving from domains to async hooks, I ran into the resource pooling problem. This is the problem where,\ngiven pool X, and requests A and B:\n\n  - request A takes out a resource from pool X.\n  - request A does work with the resource. This succeeds, the resource is associated with request A.\n  - request A returns the resource to pool X.\n  - request B takes out a resource from pool X.\n  - request B does work with the resource. This fails, the resource is still associated with request A.\n\nDomains solved this problem (mostly) through community outreach: many popular pooling libraries now include some variant\nof cb = process.domain ? process.domain.bind(cb) : cb. Internally, for all of the pools Node implements async-hooks\nappears to be well-behaved (e.g., http agents timers — incidentally, :tada: great work! :tada:) Externally, we appear to\nhave an embedder API.\n\nMy questions are:\n\n  - Do we have an AsyncResource guide for handle pool implementors?\n  - Is there a coordinated effort to reach out to popular handle pool libraries (generic-pool, pg-pool, redis, et al) to\n    add AsyncResource support?\n  - What is the CTC s plan for removing domain support? Is there a list of packages we need to upgrade before dropping\n    support?\n","created":"2017-10-09T05:37:20.000Z","hl_text":"  - Version: All\n  - Platform: All\n  - Subsystem: domain\n\n!-- Enter your issue details below this comment. --\n\nHi all 👋\n\nThe meta-problem: Many core contributors have expressed a desire to get rid of domains. ...","hl_title":"Moving from domains to async_hooks: plans for addressing common resource pools","id":"24973","num_comments":9,"number":16098,"repo":{"repository":{"id":27193779,"name":"node","owner_id":9950313,"owner_login":"nodejs","updated_at":"2024-06-08T11:57:21.714Z","has_issues":true}},"title":"Moving from domains to async_hooks: plans for addressing common resource pools","url":"/nodejs/node/discussions/16098","updated":"2022-06-29T06:29:22.000Z","user_avatar_url":"https://avatars.githubusercontent.com/u/37303?s=48&v=4","user_id":37303,"user_login":"chrisdickinson"},{"body":"I am not sure whether this is a question, bug report, or feature request, but here we go.\n\nAt the moment, it is really difficult to handle exits/signals correctly. Consider this:\n\nasync function someTask() {\n  try {\n    await someOtherTask();\n  } finally {\n    // MUST PERFORM VERY IMPORTANT CLEAN UP!\n  }\n}\n\nThis async function does not work correctly . If the process received a signal causing it to terminate, or, for some\nreason, node decided to exit due to the event loop becoming empty while waiting for the other task, the finally block do\nnot run at all.\n\nIn synchronous languages like Java, Ruby, Python, signals that are reasonable to handle are sometimes converted into\nexceptions and delivered to the currently running code . However, maybe that doesn t quite work in Node/JavaScript s\nmodel, since the function above is in fact not running , and it s unclear who should be getting these exceptions.\n\nI understand that there is no such thing as surefire cleanup , since your process can always be terminated forcefully\nwithout a chance to run any code (SIGKILL, etc), so you must be prepared to deal with the consequence of an unclean exit\nanyway.\n\nHowever, the user pressing Ctrl-C (SIGINT) isn t that unusual of a situation, and is usually expected to be as a clean\nexit, so it would be nice if we can properly cleanup after our code. Maybe in our function, we created a PID file that\nwe would like to remove, or maybe we are supposed to shutdown some children processes.\n\nOkay, so maybe we try something like this:\n\nasync function fixedFinally(task, cleanup) {\n  process.on( SIGINT , cleanup);\n  process.on( SIGTERM , cleanup);\n  // ...\n\n  try {\n    await task();\n  } finally {\n    process.off( SIGINT , cleanup);\n    process.off( SIGTERM , cleanup);\n    // ...\n\n    await cleanup();\n  }  \n}\n\nasync function someTask() {\n  await fixedFinally(someOtherTask, async () =  {\n    // MUST PERFORM VERY IMPORTANT CLEAN UP!\n  });\n}\n\nBut now, we caused another problem: when we do receive these signals (e.g. Ctrl-C), the program no longer terminates.\nThis is because by installing any handler for these signal events, it suppresses the default handler s behavior\n(terminate the program) and, as far as I know, there is no way to invoke that deafult behavior.\n\nOkay, so maybe we can just mimic the behavior of the default handler ourselves?\n\nasync function fixedFinally(task, cleanup) {\n  async function handler() {\n    await cleanup();\n    process.exit(0);\n  }\n\n  process.on( SIGINT , handler);\n  process.on( SIGTERM , handler);\n  // ...\n\n  try {\n    await task();\n  } finally {\n    process.off( SIGINT , handler);\n    process.off( SIGTERM , handler);\n    // ...\n\n    await cleanup();\n  }  \n}\n\nasync function someTask() {\n  await fixedFinally(someOtherTask, async () =  {\n    // MUST PERFORM VERY IMPORTANT CLEAN UP!\n  });\n}\n\nThis caused multiple new problems.\n\nFirst, the default behavior of the signal handlers actually exit with a non-zero exit code, according to the docs, 128 +\nsignal value. Presumably, this is for good reason and a behavior we want to match. Maybe this is not such a big deal, we\ncould probably read the docs or source code to copy the logic.\n\nBut more importantly, by calling process.exit(...) in the signal handler, the rest of the handlers (if any) will be\nskipped over! So that means if more than one async task wanted to perform cleanup in this manner, only one of them can\nsucceed.\n\nMore over, maybe some other code intentionally installed a signal handler here to avoid exiting in the first place.\nThis, in practice, means that it is unsafe for libraries to install signal handlers to perform cleanup.\n\nOkay, so since all we really care about is to perform our cleanup on exit, so perhaps this is all we needed:\n\nasync function fixedFinally(task, cleanup) {\n  process.on( exit , cleanup);\n  // ...\n\n  try {\n    await task();\n  } finally {\n    process.off( exit , cleanup);\n    // ...\n\n    await cleanup();\n  }  \n}\n\nasync function someTask() {\n  await fixedFinally(someOtherTask, async () =  {\n    // MUST PERFORM VERY IMPORTANT CLEAN UP!\n  });\n}\n\nUnfortunately, this does not work either, because the exit event is not fired when the process is terminated by the\ndefault SIGINT handler (maybe this is a bug?).\n\nSo at this point, I feel like I am not left with any good option to do async cleanup properly, especially if you are\nwriting a library and do not want to influence the global shutdown behavior just to accomplish your clanup goals.\n\nAs far as concrete suggestions on what should be done, I m not quite sure, but here are a few points to consider.\n\n  - From a DX perspective, it would be extremely nice if the async try { ... } finally { ... } Just Worked™ as it would\n    in other environments. I understand why this is perhaps a poor fit for the Node/JavaScript programming model though.\n\n  - It would have been nice if the events handlers here are designed like the browser s event APIs, where you are just\n    attaching some extra logic to run, and does not cancel the browser s default behavior by default, but there are ways\n    to do that if that s what you wish to do (preventDefault/stopPropagation). However, that ship has probably sailed.\n\n  - Under the current design, some way to invoke what-would-have-been the default handler s behavior would be nice. The\n    current behavior is like click handlers in the browser have preventDefault() on by default with no way to opt back\n    in.\n\n  - However, while the above is useful for apps , where get to decide what shutdown behavior you want, and just want to\n    run some extra logic before handing things back to the default handler, it is not enough to solve the problem for\n    libraries.\n\n  - For libraries, you really need a way to say Okay, I did what I needed to do, now just keep going as if I wasn t here\n    , which means 1) calling the rest of the signal handlers and 2) exit if no one else objects.\n\n  - Maybe the last point can be accomplished by just firing the exit event more consistently. But I m worried that there\n    are other edge cases that causes the exit event to not fire, other than the SIGINT example I discovered.\n\n  - It is also possible that I just missed some common patterns or idioms to solve this problem?\n","created":"2019-09-07T05:06:48.000Z","hl_text":"I am not sure whether this is a question, bug report, or feature request, but here we go.\n\nAt the moment, it is really difficult to handle exits/signals correctly. Consider this:\n\nasync function someTask() ...","hl_title":"Better Signal Handling","id":"24971","num_comments":24,"number":29480,"repo":{"repository":{"id":27193779,"name":"node","owner_id":9950313,"owner_login":"nodejs","updated_at":"2024-06-08T11:57:21.714Z","has_issues":true}},"title":"Better Signal Handling","url":"/nodejs/node/discussions/29480","updated":"2022-06-08T19:07:29.000Z","user_avatar_url":"https://avatars.githubusercontent.com/u/55829?s=48&v=4","user_id":55829,"user_login":"chancancode"},{"body":"AFAIK we have no rule when to check for environment variables.\n\nI see three possibilities to do so:\n\n1.  On startup\n2.  On first use\n3.  On each use\n\nSo far we mainly use 3 and some times 1. There is probably also usage of 2 but I could not find any by briefly searching\nthrough the code base.\n\nDo we want to consolidate the behavior to always follow the same rules (that might not be possible in all cases but\nprobably in most)?\n\nTo give examples for all three behaviors:\n\n// 1.\nconst env = process.env.FOOBAR;\n\nfunction abc() {\n  if (env) {\n    doThings();\n  }\n}\n\n// 2.\nlet env = null;\n\nfunction abc() {\n  if (env === null) {\n    env = process.env.FOOBAR;\n  }\n  if (env) {\n    doThings();\n  }\n}\n\n// 3.\nfunction abc() {\n  if (process.env.FOOBAR) {\n    doThings();\n  }\n}\n","created":"2019-02-20T13:30:07.000Z","hl_text":"AFAIK we have no rule when to check for environment variables.\n\nI see three possibilities to do so:\n\n1.  On startup\n2.  On first use\n3.  On each use\n\nSo far we mainly use 3 and some times 1. There is probably ...","hl_title":"Consistent environment variables","id":"24970","num_comments":24,"number":26213,"repo":{"repository":{"id":27193779,"name":"node","owner_id":9950313,"owner_login":"nodejs","updated_at":"2024-06-08T11:57:21.714Z","has_issues":true}},"title":"Consistent environment variables","url":"/nodejs/node/discussions/26213","updated":"2022-06-10T09:04:36.000Z","user_avatar_url":"https://avatars.githubusercontent.com/u/8822573?s=48&v=4","user_id":8822573,"user_login":"BridgeAR"}],"type":"discussions","page":1,"page_count":1,"elapsed_millis":74,"errors":[],"result_count":6,"facets":[],"protected_org_logins":[],"topics":null,"query_id":"","logged_in":false,"sign_up_path":"/signup?source=code_search_results","sign_in_path":"/login?return_to=https%3A%2F%2Fgithub.com%2Fsearch%3Fq%3Drepo%253Anodejs%252Fnode%2Bcreated%253A%253C2020-01-01%26type%3DDiscussions","metadata":null},"title":"Discussion search results"}