Building a NextJS Project in windows fails #26179
Assignees
Comments
marvinhagemeister
added
bug
|
got the same problem here with a completely new project |
nathanwhit
added a commit
that referenced
this issue
Oct 22, 2024
Fixes #26179. The original error reported in that issue is fixed on canary, but in local testing on my windows machine, `next build` would just hang forever. After some digging, what happens is that at some point in next build, readFile promises (from `fs/promises` ) just never resolve, and so next hangs. It turns out the issue is saturating tokio's blocking task thread pool. We previously limited the number of blocking threads to 32, and at some point those threads are all in use and there's no thread available for the file reads. What's taking up all of those threads? The answer turns out to be `tokio::process`. On windows, child process stdio uses the blocking threadpool: tokio-rs/tokio#4824. When you poll the child's stdio on windows, it spawns a blocking task per poll, and calls `std::io::Read::read` in the blocking context. That call can block until data is available. Putting it all together, what happens is that Next.js spawns `2 * the number of CPU cores` deno child subprocesses to do work. We implement `child_process` with `tokio::process`. When the child processes' stdio get polled, blocking tasks get spawned, and those blocking tasks might block until data is available. So if you have 16 cores (as I do), there are going to be potentially >32 blocking task threadpool threads taken just by the child processes. That leaves no room for other tasks to make progress --- To fix this, for now, increase the size of the blocking threadpool on windows. 4 * the number of CPU cores should be enough to leave room for other tasks to make progress. Longer term, this can be fixed more properly when we handroll our own subprocess code (needed for detached processes and additional pipes on windows).
bartlomieju
pushed a commit
that referenced
this issue
Oct 25, 2024
Fixes #26179. The original error reported in that issue is fixed on canary, but in local testing on my windows machine, `next build` would just hang forever. After some digging, what happens is that at some point in next build, readFile promises (from `fs/promises` ) just never resolve, and so next hangs. It turns out the issue is saturating tokio's blocking task thread pool. We previously limited the number of blocking threads to 32, and at some point those threads are all in use and there's no thread available for the file reads. What's taking up all of those threads? The answer turns out to be `tokio::process`. On windows, child process stdio uses the blocking threadpool: tokio-rs/tokio#4824. When you poll the child's stdio on windows, it spawns a blocking task per poll, and calls `std::io::Read::read` in the blocking context. That call can block until data is available. Putting it all together, what happens is that Next.js spawns `2 * the number of CPU cores` deno child subprocesses to do work. We implement `child_process` with `tokio::process`. When the child processes' stdio get polled, blocking tasks get spawned, and those blocking tasks might block until data is available. So if you have 16 cores (as I do), there are going to be potentially >32 blocking task threadpool threads taken just by the child processes. That leaves no room for other tasks to make progress --- To fix this, for now, increase the size of the blocking threadpool on windows. 4 * the number of CPU cores should be enough to leave room for other tasks to make progress. Longer term, this can be fixed more properly when we handroll our own subprocess code (needed for detached processes and additional pipes on windows).
|
Just FYI this should be fixed on the latest patch release |
|
This error occurred in deno 2.0.2, but was resolved in deno 2.0.4. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Failing to build a NextJS project using deno in windows.
When i use "deno task build" I get the following response :
Project works fine in dev mode using "deno task dev".
This is a project I am migrating from node so it builds & runs correctly there.
Version: deno 2.0.0 (stable, release, x86_64-pc-windows-msvc)
v8 12.9.202.13-rusty
typescript 5.6.2
The text was updated successfully, but these errors were encountered: