Since this is my first time contributing I wanted to keep it simple and I added just one function
I tested with
```bash
stage3/bin/zig build -p stage4 -Dno-lib -Dno-langref -Denable-llvm=true --search-prefix ~/repos/zig-boostrap/out/native-linux-musl-baseline/
stage4/bin/zig build test-libc -Dlibc-test-path=../libc-test -Dtest-target-filter=x86_64-linux-musl
```
and the tests passed.
I'm planning on doing more once I get the hang of it.
Co-authored-by: david <davidc.fried@gmail.com>
Reviewed-on: https://codeberg.org/ziglang/zig/pulls/30888
Reviewed-by: Andrew Kelley <andrew@ziglang.org>
Co-authored-by: Daggerfall-is-the-best-TES-game <daggerfall-is-the-best-tes-game@noreply.codeberg.org>
Co-committed-by: Daggerfall-is-the-best-TES-game <daggerfall-is-the-best-tes-game@noreply.codeberg.org>
I'm not sure where the old logic came from but it certainly didn't match NetBSD
10.1 system headers, and was causing the build system to see incorrect exit
status information for processes that were expected to crash (e.g. SIGABRT).
suggested alternatives:
- actual tests
- explicitly list the decls
- compile an example application that uses the API
- stop worrying about dead code
- refAllDecls (non recursive) in each file
Don't fight the laziness, embrace it.
closes#23608closes#30813
- remove file_size parameter from MemoryMap.write
- remove requirement for mapping length to be aligned
- align allocated fallback memory
- add unit test for std.Io.Threaded.disable_memory_mapping = true
- add unit test for MemoryMap.setLength
- change offset to u64
- make len non-optional
- make write take a file_size parameter
- std.Io.Threaded: introduce disable_memory_mapping flag to force it to
take the fallback path.
Additionally:
- introduce BlockSize to File.Stat. On Windows, based on cached call to
NtQuerySystemInformation. On unsupported OS's, set to 1.
- support File.NLink on Windows. this was available the whole time, we
just didn't see the field at first.
- remove EBADF / INVALID_HANDLE from reading/writing file error sets
by defining the pointer contents to only be synchronized after explicit
sync points, makes it legal to have a fallback implementation based on
file operations while still supporting a handful of use cases for memory
mapping.
furthermore, it makes it legal for evented I/O implementations to use
evented file I/O for the sync points rather than memory mapping.
not yet done:
- implement checking the length when options.len is null
- some windows impl work
- some wasi impl work
- unit tests
- integration with compiler
On NetBSD and Illumos, we were using the `std.Thread.Futex`-based
implementation of `std.Thread.Mutex`. But since futex is not a primitive
on these targets, the implementation of `std.Thread.Futex` was based on
pthread primitives, including `pthread_mutex_t`. This had the amusing
consequence that locking a contended mutex on NetBSD would actually
perform 2 mutex locks, 2 mutex unlocks, and 1 condition wait; likewise,
unlocking a contended mutex would perform 2 mutex locks, 2 mutex
unlocks, and 1 condition signal. Having read some cutting-edge studies,
I have concluded that this is a slightly suboptimal approach. Instead,
let's just use pthread mutexes directly in this case; that's an
obviously better idea.
In the future, I think we can probably entirely remove our usages of
pthread sync primitives---no platform actually treats them as the base
primitives. Of the platforms which std has any meaningful support for
today, most support futexes, and the exceptions (NetBSD and Illumos)
support a thread parking API. We can implement futex and/or mutex on top
of thread parking and drop the pthread dependency entirely.
Apparently the thread parking APIs on Windows and NetBSD aren't as good
as I thought---or, at least, the way they're *used* makes them not as
good. It's perfectly possible to use these APIs in a way where you don't
trigger spurious wakeups, but standard primitives (SRWLOCK on Windows,
pthread bits on NetBSD) are perfectly happy to leave pending unparks
sitting around, meaning in practice you have to assume spurious unparks
are possible. This brings me great sadness... but we soldier on!
