| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
There was a problem hiding this comment.
What if already exited?
Sorry, something went wrong.
There was a problem hiding this comment.
What if the user remove all exit event handlers?
Sorry, something went wrong.
There was a problem hiding this comment.
Isn't this changing a little too much? I think this PR could be more minimal.
Sorry, something went wrong.
There was a problem hiding this comment.
I'm unsure whether it's sufficient to wait for 'exit' or 'close' is the more correct event to wait for? Not sure exactly what the difference is between these two.
Sorry, something went wrong.
|
Let's add a closed property to child process and use the following logic: ChildProcess.prototype[SymbolAsyncDispose] = async function() {
if (!this.closed) {
await EE.once(this, 'close');
}
}; |
Sorry, something went wrong.
according to the code, exit is emitted first when child process exits, then close is fired once all the streams are drained. so we should probably use close |
Sorry, something went wrong.
we cannot use EE.once since it will always reject when calling abortChildProcess. |
Sorry, something went wrong.
There was a problem hiding this comment.
Why this? Not saying I disagree. Just not sure whether I do agree. @benjamingr any thoughts?
Sorry, something went wrong.
There was a problem hiding this comment.
So other consumers of the child process know it was aborted. this is the same behavior we've implemented on Readable[Symbol.asyncDispose]
Sorry, something went wrong.
There was a problem hiding this comment.
There is a race here though. The process might still exit successfully.
Sorry, something went wrong.
There was a problem hiding this comment.
I am Not sure I follow. can you provide an example?
Sorry, something went wrong.
There was a problem hiding this comment.
The process can succeed before it receives the kill. In which case you are emitting a bad error.
Sorry, something went wrong.
There was a problem hiding this comment.
An abortion is just a hint. The process may still choose to fully complete.
Sorry, something went wrong.
There was a problem hiding this comment.
I think this quickly becomes complicated. I'd prefer not to emit any error here.
Sorry, something went wrong.
There was a problem hiding this comment.
it can be a surprising behavior for a child process to exit without a kill signal and a code, and with incomplete stdout/stderr
Sorry, something went wrong.
There was a problem hiding this comment.
Let's ask for @ronbuckton 's advice:
The question here is:
await using cp = childProcess1;
// someOtherCode
doSomethingWith(childProcess1);What should the behavior be from doSomethingWith's side? For example if someone is reading stdout while another consumer is disposing it should it error?
Sorry, something went wrong.
|
Any signal other than SIGKILL may actually be ignored by the process. Which would lead to a deadlock in our case. |
Sorry, something went wrong.
a pending promise is not a deadlock |
Sorry, something went wrong.
|
It is if you wait for it, expecting it to resolve and it never does |
Sorry, something went wrong.
|
I'd like to have some more opinions on this. I feel there is a risk of this being an anti-pattern that we encourage. |
Sorry, something went wrong.
|
Maybe we can get around the deadlock issue by always having a timeout which eventually calls sigkill and makes sure the promise will eventually resolve. |
Sorry, something went wrong.
|
An alternative is to implement dispose and not asyncDispose, send the signal and wait for nothing. If someone wants to wait for the process to terminate they can do so by listening to the event themselves. |
Sorry, something went wrong.
I think this is the only reasonable option given we don't know how to wait for the process to terminate "for sure" |
Sorry, something went wrong.
Sorry, something went wrong.
Sorry, something went wrong.
PR-URL: #48551 Reviewed-By: Robert Nagy <ronagy@icloud.com> Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
PR-URL: nodejs#48551 Reviewed-By: Robert Nagy <ronagy@icloud.com> Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
PR-URL: nodejs#48551 Reviewed-By: Robert Nagy <ronagy@icloud.com> Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
PR-URL: #48551 Reviewed-By: Robert Nagy <ronagy@icloud.com> Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
PR-URL: #48551 Reviewed-By: Robert Nagy <ronagy@icloud.com> Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
PR-URL: #48551 Reviewed-By: Robert Nagy <ronagy@icloud.com> Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
| Back | FazBrowse Home | New Git URL |
No description provided.