An `Io.Mutex` is bound to the Io implementation used to lock and unlock it: having it cross Io implementations could already be an abuse of the API. C code is even further removed, since it has no `Io` at all and could never meaningfully interact with an `Io.Mutex`, so making it `extern` doesn't buy us anything. The only thing we actually gain is less boilerplate when the user needs to protect a struct that is also used from C, where the C side doesn't need the synchronization. I would argue that's not a strong enough reason to keep it `extern`, since the same behavior can be achieved with composition.
Being `extern` also conflicts with adding safety features to the implementation: their size would change with the compilation configuration, which defeats the purpose of `extern`.
Reviewed-on: https://codeberg.org/ziglang/zig/pulls/37081
Reviewed-by: Andrew Kelley <andrew@ziglang.org>
It is not clear to me that this is the right path to take, using a
shared buffer for control data makes managing the alignment trickier,
and would require the Io interface itself to deal with alignment.
For an example of what I consider clean design, see net_read/net_write.
There is no need for the Io interface/operations to be aware of control
buffer alignment and it is sufficient for the net.Stream.Reader
abstraction to use an aligned buffer.
Also this has no test coverage and is (to my knowledege)
not currently blocking any real world Zig project.
This reverts commit 7c0347fce0b6f510b43ca503ad9c1cd2f8ac9a6b.
Also adds a way to read control data using Stream.Reader. Stream.Reader
will buffer control data until it can't no more, in which case it will
be truncated.
The readv syscall in netReadPosix has been replaced with recvmsg.
A couple of changes to improve reception of control data when using the
datagram API.
Instead of having a separate control buffer per received message,
there's one big buffer that all messages share (like the data buffer).
This means that now IncomingMessage has no user-initialised fields, and
can be initialised with undefined (which means that .init is now
deprecated).
Also, instead of taking a pointer to mutable IncomingMessage,
netReceiveOne* functions simply return a IncomingMessage.
When `std.Io.Condition` is signaled and almost immediately after
that canceled, it will swallow the `error.Canceled` error and
leave the task in an uncancelable state.
Co-authored-by: Lukas Lalinsky <lukas@lalinsky.com>
Reviewed-on: https://codeberg.org/ziglang/zig/pulls/35564
Reviewed-by: mlugg <mlugg@mlugg.co.uk>
Also adds sendTimeout() and sendManyTimeout() functions to
Io.net.Socket, and updates the UDP tests to exercise all of the
combined interfaces.
Deprecates `sendMany` in favor of `sendManyTimeout` with a
`Timeout` of `.none`. The existing `sendMany` interface is not
capable of reporting partial success, and eventually removing it
will align with the current interfaces on the receive side.
Seems to work for Posix + Threaded? Beyond very basic "avoid
compile errors maybe", I have not tried to address non-Posix or
non-Threaded parts.
Timeout.none implicitly seems to mean indefinitely nearly
everywhere I can see. However, Io.Threaded.sleep() has a
short-circuit at the top which treats Timeout.none as effectively
zero (no sleep at all), even though the per-target functions it
calls afterwards would otherwise would honor .none correctly.
This patch removes this (presumably erronenous) short-circuit and
documents Timeout.none's meaning explicitly.
makes the build system compile on 32 bit systems
bonus, also fix incorrectly passing advanced debug options to the maker
process which doesn't care about them
I'd have preferred if `vtable.futexWait` returned `error.Timeout`, since
all the OS-level APIs provide it. However, if I keep the vtable untouched,
I had to determine the timeout case by post-checking the deadline.
It's fine functionally, but one extra syscall that be avoided at
cost of changing the vtable and all the futex implementations.
The logic used to allow providing a path for setting the CWD of a child process in https://codeberg.org/ziglang/zig/pulls/31090 applies here as well:
- Windows must provide a path when setting the CWD, so the path of an `Io.Dir` must be resolved before actually calling RtlSetCurrentDirectory_U
- A directory handle may have multiple paths associated with it, so providing the CWD as a string retains a legitimate use case in cases where the precise path matters
While the general guidance remains useful, it is not the case that
error.Canceled will always pass across the Group task function boundary.
Remove the too-aggressive assertions and add unit test coverage.
Closes#30096Closes#31340Closes#31358
Remove the `{D}` format specifier. It is moved into `std.Io.Duration` as
a format method.
Migration plan:
```diff
-writer.print("{D}", .{ns});
+writer.print("{f}", .{std.Io.Duration{ .nanoseconds = ns }});
```
All instances where `{D}` was used have been changed to use
`std.Io.Duration` and `{f}`.
Fixes#31281
and make the return value of `cancel` return queue items.
I don't think it's possible to make `cancel` not deadlock with an empty
queue buffer without introducing a new Group primitive.
This is the best I could come up with based on existing primitives.
Let's see if applications find these APIs palatable.
This function works with a slice of futures and returns the index of a
completed one. This doesn't work very well in practice because it's
either too high level or too low level.
At the lower level we have Io.Batch for doing this kind of thing at the
Operation API layer.
At the higher level we have Io.Select which is a convenience wrapper
around an Io.Group and an Io.Queue.
Giuseppe Cesarano