Hacker News Reader

Comment by mfenniak | Hacker News Reader

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 syscalls then they become async automatically.

I don't think it's appropriate for the level of coding that Rust is targeting... But... It would be nice.

View on HN

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.

> 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

> 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.

O_NONBLOCK

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.

Reply on news.ycombinator.com