This decision should be audited and discussed.
Some factors:
* Passing an Io instance into start.
* Avoiding reference to global static instance if it won't be used, so
that it doesn't bloat the executable.
* Being able to use std.debug.print, and related functionality when
debugging std.Io instances and std.Progress.
instead, allow the user to set it as a field.
this fixes a bug where leak printing and error printing would run tty
config detection for stderr, and then emit a log, which is not necessary
going to print to stderr.
however, the nice defaults are gone; the user must explicitly assign the
tty_config field during initialization or else the logging will not have
color.
related: https://github.com/ziglang/zig/issues/24510
The 6.17 kernel added[1] syscalls for getting/setting certain file flags
and attributes. It's meant to be a more extensible replacement for these
ioctl's:
- `FS_IOC_GETFLAGS`/`FS_IOC_SETFLAGS`.
- `FS_IOC_FSGETXATTR`/`FS_IOC_FSSETXATTR`.
The definitions of these calls are as follows:
```zig
const file_attr = extern struct {
/// Extended flags that apply to this file. (get/set).
xflags: u64,
/// Preferred extent allocation size, in bytes. (get/set).
extsize: u32,
/// One of:
/// - The number of data extents in this file.
/// - If `FS_IOC_FSGETXATTRA` is set, the number of extended attribute events in the file.
/// (get)
nextents: u32,
/// Project Identifier (get/set).
projid: u32,
/// Preferred extent allocation size for CoW operations, in bytes (get/set).
cowextsize: u32,
};
// size=@sizeOf(file_attr)
fn file_getattr(dirfd: fd_t, path: [*:0], fattr: *file_attr, size: usize, at_flags: u32) {}
fn file_setattr(dirfd: fd_t, path: [*:0], fattr: *file_attr, size: usize, at_flags: u32) {}
```
Users need to set/check `xflags` with the `FS_XFLAG` flags defined in
`linux/fs.h`. `ioctl_xfs_fsgetxattr(2)` has more information about the
type of information one can retrieve.
[1]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=57fcb7d930d8f00f383e995aeebdcd2b416a187a
More tasks could be added to the group at any time before it completes,
so it's not valid to look at the `token` passed in here.
There's also a related bug in `Threaded`, which is that tasks spawned in
a group after it is canceled will not observe that cancelation, but that
is a more complex bug which needs some deeper design changes.
Queues can now be "closed". A closed queue cannot have more elements
appended with `put`, and blocked calls to `put` will immediately unblock
having failed to append some elements. Calls to `get` will continue to
succeed as long as the queue buffer is non-empty, but will then never
block; already-blocked calls to `get` will unblock.
All queue get/put operations can now return `error.Closed` to indicate
that the queue has been closed. For bulk get/put operations, they may
add/receive fewer elements than the minimum requested *if* the queue was
closed or the calling task was canceled. In that case, if any elements
were already added/received, they are returned first, and successive
calls will return `error.Closed` or `error.Canceled`.
Also, fix a bug where `Queue.get` could deadlock because it incorrectly
blocked until the given buffer was *filled*.
Resolves: #30141
Andrew Kelley