fix(pack): lock turbopack cache before persistent writes

[fireairforce]

Summary

to solve windows persistent cache parallel write cuase os error 5:

closes: #2912

Align turbopack's: vercel/next.js#84428

Test Plan

[gemini-code-assist]

Code Review

This pull request introduces a cross-platform persistent cache locking mechanism to prevent concurrent processes from accessing the same .turbopack cache. The implementation includes a native Rust module for file locking, integrated into the build and development workflows via NAPI. Feedback was provided regarding the use of a synchronous file system operation within an asynchronous function, which could potentially block the event loop.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 6fbe61f567

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[github-actions]

📊 Performance Benchmark Report (with-antd)

Utoopack Performance Report

Report ID: utoopack_performance_report_20260511_164907
Generated: 2026-05-11 16:49:07
Trace File: trace_antd.json (0.5GB, 1.57M spans)
Test Project: examples/with-antd

---

Executive Summary

Metric	Value	Assessment
Total Wall Time	12,469.2 ms	Baseline
Total Thread Work (de-duped)	24,271.9 ms	Non-overlapping busy time
Effective Parallelism	1.9x	thread_work / wall_time
Working Threads	5	Threads with actual spans
Thread Utilization	38.9%	⚠️ Suboptimal
Total Spans	1,565,362	All B/E + X events
Meaningful Spans (>= 10us)	386,861	(24.7% of total)
Tracing Noise (< 10us)	1,178,501	(75.3% of total)

---

Build Phase Timeline

Shows when each build phase is active and how much CPU it consumes.
Self-Time is the time spent exclusively in that phase (excluding children).

Phase	Spans	Inclusive (ms)	Self-Time (ms)	Wall Range (ms)
Resolve	84,742	2,413.7	1,894.4	4,987.3
Parse	10,510	1,802.0	1,538.1	12,341.2
Analyze	226,967	14,238.1	9,894.8	11,931.2
Chunk	23,265	2,516.1	2,365.1	8,053.0
Codegen	31,712	4,391.4	3,236.7	8,104.6
Emit	39	43.1	21.4	8,292.1
Other	9,626	1,391.5	1,224.3	12,469.2

---

Workload Distribution by Diagnostic Tier

Category	Spans	Inclusive (ms)	% Work	Self-Time (ms)	% Self
P0: Scheduling & Resolution	318,518	17,592.9	72.5%	12,580.1	51.8%
P1: I/O & Heavy Tasks	3,083	137.0	0.6%	115.3	0.5%
P2: Architecture (Locks/Memory)	0	0.0	0.0%	0.0	0.0%
P3: Asset Pipeline	64,038	8,696.1	35.8%	7,126.5	29.4%
P4: Bridge/Interop	0	0.0	0.0%	0.0	0.0%
Other	1,222	370.0	1.5%	352.9	1.5%

---

Top 20 Tasks by Self-Time

Self-time is the exclusive duration: time spent in the task itself, not in sub-tasks.
This is the most accurate indicator of where CPU cycles are actually spent.

Self (ms)	Inclusive (ms)	Count	Avg Self (us)	P95 Self (ms)	Max Self (ms)	% Work	Task Name	Top Caller
5,307.6	7,714.2	147,206	36.1	0.1	34.6	21.9%	module	write all entrypoints to disk (1%)
2,344.0	2,369.6	28,125	83.3	0.2	185.6	9.7%	analyze ecmascript module	module (66%)
1,821.5	2,976.2	18,892	96.4	0.4	45.3	7.5%	code generation	chunking (2%)
1,607.0	1,732.4	13,518	118.9	0.3	79.5	6.6%	chunking	write all entrypoints to disk (0%)
1,341.9	3,226.0	41,340	32.5	0.0	7.0	5.5%	process module	module (14%)
1,198.5	1,273.4	7,456	160.7	0.6	38.9	4.9%	parse ecmascript	process module (29%)
1,132.7	1,239.0	47,363	23.9	0.0	6.0	4.7%	internal resolving	resolving (29%)
1,054.5	1,054.5	10,737	98.2	0.3	12.4	4.3%	precompute code generation	code generation (55%)
842.7	982.9	7,746	108.8	0.0	195.9	3.5%	write all entrypoints to disk	None (0%)
786.5	786.5	7,526	104.5	0.4	88.6	3.2%	compute async module info	chunking (0%)
748.4	1,161.4	36,688	20.4	0.0	6.0	3.1%	resolving	module (14%)
730.7	731.1	9,659	75.7	0.0	58.1	3.0%	compute async chunks	webpack loader (0%)
360.8	360.8	2,083	173.2	0.5	17.8	1.5%	generate source map	code generation (96%)
307.1	316.1	1,059	290.0	1.0	21.6	1.3%	webpack loader	parse css (11%)
259.1	448.1	701	369.6	1.8	28.4	1.1%	parse css	module (6%)
80.4	80.4	2,341	34.3	0.0	3.1	0.3%	read file	parse ecmascript (91%)
67.1	67.1	904	74.3	0.0	16.0	0.3%	compute binding usage info	write all entrypoints to disk (0%)
32.7	32.7	1,841	17.8	0.0	6.2	0.1%	collect mergeable modules	compute merged modules (0%)
28.7	38.7	658	43.6	0.1	3.3	0.1%	async reference	write all entrypoints to disk (1%)
27.3	52.6	88	310.4	0.6	19.2	0.1%	make production chunks	chunking (5%)

---

Critical Path Analysis

The longest sequential dependency chains that determine wall-clock time.
Focus on reducing the depth of these chains to improve parallelism.

Rank	Self-Time (ms)	Depth	Path
1	185.6	2	process module → analyze ecmascript module
2	63.1	2	code generation → generate source map
3	48.5	2	module → analyze ecmascript module
4	47.4	2	module → analyze ecmascript module
5	43.3	2	code generation → generate source map

---

Batching Candidates

High-volume tasks dominated by a single parent. If the parent can batch them,
it drastically reduces scheduler overhead.

Task Name	Count	Top Caller (Attribution)	Avg Self	P95 Self	Total Self
No obvious batching candidates found	-	-	-	-	-

---

Duration Distribution

Range	Count	Percentage
<10us	1,178,501	75.3%
10us-100us	362,401	23.2%
100us-1ms	20,081	1.3%
1ms-10ms	4,244	0.3%
10ms-100ms	131	0.0%
>100ms	4	0.0%

---

Action Items

1. [P0] Focus on tasks with the highest Self-Time — these are where CPU cycles are actually spent.
2. [P0] Use Batching Candidates to identify callers that should use try_join or reduce #[turbo_tasks::function] granularity.
3. [P1] Check Build Phase Timeline for phases with disproportionate wall range vs. self-time (= serialization).
4. [P1] Inspect P95 Self (ms) for heavy monolith tasks. Focus on long-tail outliers, not averages.
5. [P1] Review Critical Paths — reducing the longest chain depth directly improves wall-clock time.
6. [P2] If Thread Utilization < 60%, investigate scheduling gaps (lock contention or deep dependency chains).

Report generated by Utoopack Performance Analysis Agent