Re-enable unref in Deno#3701
Conversation
This re-enables unref-by-default in Deno, and fixes the event loop starvation issue by explicitly re-ref'ing the esbuild sub-process when a user calls `stop()`.
| // Ref the child process again, so that a user calling `close()` can await | ||
| // the returned promise without the event loop starving because there are | ||
| // no more ref'd async tasks. | ||
| child.ref() |
There was a problem hiding this comment.
This is the only new code. All other code is just a revert of 116f63e.
| // You may also start esbuild once at the top level of your test suite (by | ||
| // calling `initialize()`) instead of starting and stopping the esbuild process | ||
| // for every test. This will not interfere with the resource sanitizer, and will | ||
| // improve the efficiency of your tests because the esbuild process can be | ||
| // reused between tests. |
There was a problem hiding this comment.
I have added this paragraph to explain that you may also start esbuild outside of a Deno.test call to avoid the resource sanitizer flagging it.
|
@evanw Could you take a look at this? |
|
Just a heads up, I wouldn't be surprised if error about not being able to initialize esbuild bin folder are related to this because things are running when they shouldn't be running. It looks like some kind of race condition in that case. |
|
@gmzacharydovel the issue you liked to is an issue with |
|
@marvinhagemeister I want to believe that, but it is happening on a already installed project. Furthermore, the error disappears/appears in ways that make it looks like a race condition. I appreciate that being raised and I'll try to keep my eye out if Deno is trying to do some kind of hidden install process, but I have my doubts. |
3 participants
This re-enables unref-by-default in Deno, and fixes the event loop starvation issue by explicitly re-ref'ing the esbuild sub-process when a user calls
stop().Background: #3682 (comment)