3 ms·

I believe this is reference to Go's approach, where code can be written in a linear straightforward fashion with normal function calls, but, if they are syscall

• aw1621107 2y ago
  I suppose that makes sense given OP's definition of "no dependence on run times", but I think I'd have to agree that that approach probably wouldn't work well for the niche Rust is trying to target.
• worik 2y ago
  > I believe this is reference to Go's approach, I am unfamiliar with GO. I am thinking of the way the C library does it. > I don't think it's appropriate for the level of coding that Rust is targeting That would be low level system programming. In part
  • aw1621107 2y ago
    > I am thinking of the way the C library does it. What way is that? I didn't think the C standard library had any understanding of blocking/non-blocking.
    • worik 2y ago
      O_NONBLOCK
      • aw1621107 2y ago
        That's technically POSIX, not standard C, isn't it? But in any case, I'm pretty sure Rust has supported the nonblocking functionality you want for quite a while now (maybe since 1.1.0)? You'll need to piece it together yourself and use the libc crate since it's a platform-specific thing, but it doesn't seem too horrendous. Ultimately it comes down to the fact that the fundamental method for the std:io::Read is fn read(&mut self, buf: &mut [u8]) -> std::io::Result<usize>; which is perfectly compatible with non-blocking reads. For example, std::io::File implements Read and std::os::fd::FromRawFd, so if you can get a non-blocking file descriptor you should have non-blocking reads for files.