Rewriting the GNU Coreutils in Rust [LWN.net]

Rewriting the GNU Coreutils in Rust

Posted Jun 15, 2021 12:44 UTC (Tue) by epa (subscriber, #39769)
In reply to: Rewriting the GNU Coreutils in Rust by Sesse
Parent article: Rewriting the GNU Coreutils in Rust

What you say is quite right in general but I am talking about coreutils specifically. Those are short-lived command line programs with no event loop. (And, I would suggest, any program where the programmer hasn't explicitly decided to allow for signal handling and interruptions. The default should be to retry automatically, simulating a world in which EINTR doesn't exist, but of course the standard library should include an interruptible variant of each operation you can call explicitly and handle the error explicitly.)

to post comments

Rewriting the GNU Coreutils in Rust

Posted Jun 15, 2021 19:02 UTC (Tue) by nix (subscriber, #2304) [Link] (2 responses)

> Those are short-lived command line programs with no event loop

Many, perhaps most of the commands in coreutils are or can operate as filters. These can be arbitrarily long-lived and spend nearly all their time blocked on I/O.

Rewriting the GNU Coreutils in Rust

Posted Jun 16, 2021 5:03 UTC (Wed) by epa (subscriber, #39769) [Link] (1 responses)

Right, but they are not event driven. At least not in the classical implementation. Maybe with the Rust implementation it’s much more parallelized, there is cleanup work to do on being interrupted, and so you do need to explicitly check for system calls giving EINTR and do something other than just retrying. I still think Rust’s error handling mechanisms will make that cleaner than in C.

Rewriting the GNU Coreutils in Rust

Posted Jun 16, 2021 14:46 UTC (Wed) by nix (subscriber, #2304) [Link]

Oh, definitely. The need to wrap everything in either if statements or EINTR-checking while loops makes robust C unbelievably ugly compared to Rust of corresponding robustness, where you usually just need a trailing ?.