Comment by orf
16 hours ago
The linked thread here[1] is… illuminating. The Zig stdlib seems pretty buggy, and the much applauded IO interfaces seem to be struggling with cancellation. The BDFL doesn’t seem to have much to say other than “brush your teeth”
1. https://ziggit.dev/t/making-it-harder-to-swallow-error-cance...
No, that's not the best description. The Io interface is actually one of the best cancellation stories out there. If you combine it with defer/errdefer, you get safer cancellation guarantees than you have in async Rust (you can do async "drop" for example). The only problematic part is the interaction between the Reader/Writer interface and the Io interface, with regards to error handling.
> The only problematic part is the interaction between the Reader/Writer interface and the Io interface, with regards to error handling.
The fact that error handling suffers when combining two of the base interfaces of the standard library is pretty rough though? I don't think rust has that particular problem.
It's a different approach to Rust. There, if you cancel a future, it stops polling and runs the Drop interface. You don't get to do more complex cleanup. But, at the same time, because cancellation is not an error that all functions have to propagate, it's structurally not possible to ignore it. Zig, like many other languages, uses a specific error to indicate cancellation. The application can decide what to do with it, it has some benefits. But unlike Python/Java where exceptions can he thrown from anywhere, Zig errors need to be named and that's where to issues comes from, because the Reader/Writer interfaces no longer are generic, they can't pass the concrete errors returned from the implementations, and cancellation is one of the errors that get hidden that way. It's a comprise either way, Zig would need to have first class support for comptime interfaces/traits to solve it better, but that's not going to happen. So in the meantime, there is a dilema how to handle it, but I'm sure it will get solved, or at least best practices will get developed.
10 replies →
Cancellation in Rust is problematic too but for other reasons than cancellation in Zig is problematic. Maybe there is just no free lunch here, but hopefully it can be fixed in Zig and Rust.
The answer from Andrew sounds like that because there is a history between people from the core team and lalinsky.
Yeah, sounds like they're on good terms. The top replier to the GP disagrees with the GP's mischaracterization.
Not a zig person, but the post you linked has a good counter example on why the proposal for adding cancellation to the interface is bad: You would be forcing cancellation semantics on interfaces that might not want nor be able to provide one. Forcing a new method because the libraries are not well designed does not seem right for me. Maybe another solutions is available, but that is not one.
I get the pain, but the answer from Scott Redig totally makes sense. I am not sure what is worse: Libraries swallowing cancelled() or libraries lying that they support cancelled.
The point is libraries are agnostic. You as a library user provide io transport and loop implementation which supports/not supports cancelation. And you as as library user handle cancelation.
> Libraries swallowing cancelled() or libraries lying that they support cancelled.
For me former is obviously worse.