Subcompilation fails when build-exe executed in parallel #9439
Labels
Milestone
Comments
|
Out of curiosity, could you try setting the |
|
Running the same tests (with unique Some files were kept in |
andrewrk
added
the
bug
|
Reminder to ping the thread of #10157 when this is solved and make sure it solved that issue too. |
|
Reminder to ping the thread of #10158 when this is solved and make sure it solved that issue too. |
|
I've spent a few hours looking into this today and it'll take me another day or two but I've diagnosed the problems and I know how to solve them. The bad news is that fixing #9836 is not possible without hamstringing our std.fs API guarantees, but the good news is that #9836 does not appear to be the cause of this bug. It's something more related to the innards of the compiler. Anyway I'm confident I can fix it soon and I'm actively working on it. |
andrewrk
added a commit
that referenced
this issue
Dec 6, 2021
All Zig code is eligible to `@import("builtin")` which is mapped to a
generated file, build.zig, based on the target and other settings.
Zig invocations which share the same target settings will generate the
same builtin.zig file and thus the path to builtin.zig is in a shared
cache folder, and different projects can sometimes use the same file.
Before this commit, this led to race conditions where multiple
invocations of `zig` would race to write this file. If one process
wanted to *read* the file while the other process *wrote* the file, the
reading process could observe a truncated or partially written
builtin.zig file.
This commit makes the following improvements:
- limitations:
- avoid clobbering the inode, mtime in the hot path
- avoid creating a partially written file
- builtin.zig needs to be on disk for debug info / stack trace purposes
- don't mark the task as complete until the file is finished being populated
(possibly by an external process)
- strategy:
- create the `@import("builtin")` `Module.File` during the AstGen
work, based on generating the contents in memory rather than
loading from disk.
- write builtin.zig in a separate task that doesn't have
to complete until the end of the AstGen work queue so that it
can be done in parallel with everything else.
- when writing the file, first stat the file path. If it exists, we are done.
- otherwise, write the file to a temp file in the same directory and atomically
rename it into place (clobbering the inode, mtime in the cold path).
- summary:
- all limitations respected
- hot path: one stat() syscall that happens in a worker thread
This required adding a missing function to the standard library:
`std.fs.Dir.statFile`. In this commit, it does open() and then fstat()
which is two syscalls. It should be improved in a future commit to only
make one.
Fixes #9439.
andrewrk
added a commit
that referenced
this issue
Dec 7, 2021
All Zig code is eligible to `@import("builtin")` which is mapped to a
generated file, build.zig, based on the target and other settings.
Zig invocations which share the same target settings will generate the
same builtin.zig file and thus the path to builtin.zig is in a shared
cache folder, and different projects can sometimes use the same file.
Before this commit, this led to race conditions where multiple
invocations of `zig` would race to write this file. If one process
wanted to *read* the file while the other process *wrote* the file, the
reading process could observe a truncated or partially written
builtin.zig file.
This commit makes the following improvements:
- limitations:
- avoid clobbering the inode, mtime in the hot path
- avoid creating a partially written file
- builtin.zig needs to be on disk for debug info / stack trace purposes
- don't mark the task as complete until the file is finished being populated
(possibly by an external process)
- strategy:
- create the `@import("builtin")` `Module.File` during the AstGen
work, based on generating the contents in memory rather than
loading from disk.
- write builtin.zig in a separate task that doesn't have
to complete until the end of the AstGen work queue so that it
can be done in parallel with everything else.
- when writing the file, first stat the file path. If it exists, we are done.
- otherwise, write the file to a temp file in the same directory and atomically
rename it into place (clobbering the inode, mtime in the cold path).
- summary:
- all limitations respected
- hot path: one stat() syscall that happens in a worker thread
This required adding a missing function to the standard library:
`std.fs.Dir.statFile`. In this commit, it does open() and then fstat()
which is two syscalls. It should be improved in a future commit to only
make one.
Fixes #9439.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Executing the zig compiler (specifically
zig build-exe) multiple times in parallel can occasionally cause subcompilations to fail. This issue is present on both Ubuntu and Windows, running from the master branch. A sample of error messages:This can happen during CI runs (1, 2). In this project, I'm using
zigas essentially a portable linker, so the test suite callsbuild-exedozens of times in different threads. Without changes to my code, the same test can succeed or fail seemingly at random.At a guess, it looks like there might be a race condition between different invocations of the compiler writing to and reading from files.
The text was updated successfully, but these errors were encountered: