Commit 87a25dc
authored
[ports] Unpack ports atomically to improve concurrency robustness (#27161)
When building ports in parallel, different processes can race on
checking
the port's up-to-date status. Currently, we unpack directly into the
target
directory and then write the marker file. This creates a window of time
where the directory exists but is incomplete and lacks the marker.
If another process checks the port status during this window, it will
conclude the port is invalid/incomplete, and aggressively delete the
directory and its cached builds to re-unpack it. This can disrupt other
processes currently compiling from that directory or lead to
EM_CACHE_IS_LOCKED errors when child processes try to rebuild deleted
libraries.
By unpacking to a temporary directory and atomically renaming it to the
final destination, we ensure that the target directory either does not
exist at all or is 100% complete with the marker. This eliminates the
partially unpacked state and leverages the atomicity of directory
rename (which is highly coherent in OS VFS layers) to reduce the race
window to zero.
This should help resolve intermittent bot failures on macOS and Windows,
where VFS metadata latency can cause processes to see inconsistent
directory
states.
Hopefully this will address #27160, although time will tell.1 parent 8f23d7b commit 87a25dc
1 file changed
Lines changed: 16 additions & 3 deletions
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
373 | 373 | | |
374 | 374 | | |
375 | 375 | | |
376 | | - | |
377 | | - | |
378 | | - | |
| 376 | + | |
| 377 | + | |
| 378 | + | |
| 379 | + | |
| 380 | + | |
| 381 | + | |
| 382 | + | |
| 383 | + | |
| 384 | + | |
| 385 | + | |
| 386 | + | |
| 387 | + | |
| 388 | + | |
| 389 | + | |
| 390 | + | |
| 391 | + | |
379 | 392 | | |
380 | 393 | | |
381 | 394 | | |
| |||
0 commit comments