This commit changes how `std.io.poll` is implemented on Windows. The new
implementation unfortunately incurs a little extra system call overhead,
but fixes a major bug in the old implementation.
I'm not yet set on this implementation, but I'm pushing it to check if
it resolves my CI failures.
The old implementation was buggy in that by leaving `ReadFile` calls
into the `LinearFifo` write end pending between `poll` calls, there was
potential for a race condition where the kernel satisfies the
asynchronous read after the caller has modified the corresponding
`LinearFifo` in some way; most likely by rotating its buffer for a
`readableSliceOfLen` call. The only way to allow the full `LinearFifo`
API to be used is to not leave these `ReadFile` calls pending after
`poll` returns. So, now, `pollWindows` will leave running a different
set of `ReadFile` calls, which are trying to read a single byte into a
temporary buffer. These are the operations we wait on with
`WaitForMultipleObjects`. When these reads are completed, we push that
single byte to the FIFO, and perform some reads directly into the FIFO
memory until we stop getting immediate results; then, we again queue a
single-byte read into a stable buffer for the next call to `poll`.
My main concern with this implementation is that if the kernel
frequently returns `IO_PENDING` for `ReadFile` calls even when the data
is available, then we could effectively skip the bulk-reading path,
hence reading data one byte at a time. Performance measurements are
necessary here.
Throw another target in there just to spice things up a little!
Running the incremental cases with the C backend is pretty slow due to
the need to recompile the whole output from scratch on every update; for
this reason, we probably don't want to keep many of these targeting CBE
long-term. However, for now, while we have relatively few tests and
things are still changing quite a lot, it's better to have this little
bit of extra test coverage.
If no external executor is available for a successful binary, its
execution is silently skipped. This allows the CI to test, to the
fullest extent possible, incremental cross-compilation to targets whose
binaries can't be executed on the host.
This is contained in the `test` step, so is tested by CI.
This commit also includes some enhancements to the `incr-check` tool to
make this work correctly.
This experimental target has no recent active maintainer. It's the only
linker backend complaining about this branch and I can't make sense of
the stack trace.
This can be fixed asynchronously by anyone who wants to maintain plan9
support. It does not need to block this branch.
although they would also pass simply reverted to master branch because
I made the deprecated API still work for now (to be removed after 0.14.0
is tagged)
Introduces `std.builtin.Panic` which is a complete interface for
panicking. Provide `std.debug.FormattedPanic` and
`std.debug.SimplePanic` and let the user choose, or make their own.
Fixes#21446
Both UefiPoolAllocator and UefiRawPoolAllocator were
passing the value of `log2_ptr_align` directly to
`mem.alignAllocLen` which expects a alignment value.
Both of these calls to `mem.alignAllocLen` are pointless
and the result of the alignment both always true, and
was thrown away anyway.
I have removed these calls entirely.
