Setting a `File` non-blocking

[joshtriplett]

Proposal

Problem statement

While ordinary files don't typically have non-blocking support, File can also work for device files and similar (as well as other kinds of devices put into a File via File::from), and in this case, it can make sense to open them in non-blocking mode, or toggle them in and out of that mode.

I'd like to be able to do this without using a third-party crate like rustix to perform the open, and without having to use custom_flags (and define the target-specific constant for the flag).

Motivating examples or use cases

In a test program I'm writing, I'd like to open /dev/kmsg. That file needs to be opened in non-blocking mode if you want to detect the end of the current available messages, because it never produces EOF; it will block indefinitely waiting for more messages, or return EAGAIN if in non-blocking mode.

Solution sketch

// In std::os::unix::fs::OpenOptionsExt:
fn nonblocking(&mut self, nonblocking: bool) -> &mut Self;

// In std::os::unix::fs::FileExt:
pub fn set_nonblocking(&self, nonblocking: bool) -> Result<()>;

These should have appropriate documentation stating that they don't typically work on ordinary files the way people would expect, and primarily have use for things like devices, pipes, and similar.

What happens now?

This issue contains an API change proposal (or ACP) and is part of the libs-api team feature lifecycle. Once this issue is filed, the libs-api team will review open proposals as capability becomes available. Current response times do not have a clear estimate, but may be up to several months.

Possible responses

The libs team may respond in various different ways. First, the team will consider the problem (this doesn't require any concrete solution or alternatives to have been proposed):

• We think this problem seems worth solving, and the standard library might be the right place to solve it.
• We think that this probably doesn't belong in the standard library.

Second, if there's a concrete solution:

• We think this specific solution looks roughly right, approved, you or someone else should implement this. (Further review will still happen on the subsequent implementation PR.)
• We're not sure this is the right solution, and the alternatives or other materials don't give us enough information to be sure about that. Here are some questions we have that aren't answered, or rough ideas about alternatives we'd want to see discussed.

[the8472]

That kind of seems like an edge case that otherwise offers very little on its own. Most things that need non-blocking also need polling, which std doesn't offer either.

And once we have #641 you could do to_view::<UdpSocket>().set_nonblocking(true)

[programmerjake]

And once we have #641 you could do to_view::<UdpSocket>().set_nonblocking(true)

that seems kinda obtuse whenever you don't actually have a UDP socket

[the8472]

Sure but imo we shouldn't replicate API across all file-ish objects. They're all FDs, but we pretend they're different things so we can have grouped APIs.

Perhaps things that make sense across many types should be a trait instead of inherent methods?

[ChrisDenton]

Most things that need non-blocking also need polling, which std doesn't offer either.

This does seem very pertinent. If you usually need libc (or another library) anyway then having this specific function in std seems to be of pretty marginal utility? Even if there are niche cases where it helps (but that's true for a lot of libc functions).

[joshtriplett]

That kind of seems like an edge case that otherwise offers very little on its own. Most things that need non-blocking also need polling, which std doesn't offer either.

We should, eventually. But non-blocking is still useful as an incremental step. And even if you end up using some other library for other parts of the problem, non-blocking is a part of opening a file, and we have support for opening a file.

I also think that we need set_nonblocking in some generic location. We could put it on OwnedFd, for instance, but our various discussions around files have trended towards "put it in a File if you want to manipulate it". So, this is useful for anything that has a file descriptor and wants to put it into non-blocking mode: .as_view::<File>().set_nonblocking(true).

[programmerjake]

And even if you end up using some other library for other parts of the problem, non-blocking is a part of opening a file

ah, for that part you have to specify non-blocking when calling open, otherwise open can block when opening fifo files that don't have any other readers/writers yet. it can also block for file leases. There's other ways to block on non-unix, but those may or may not have a non-blocking equivalent.

(edit: I missed that there's a proposed function for opening too)

[joshtriplett]

(edit: I missed that there's a proposed function for opening too)

Exactly. My primary goal here was to provide a way to open with O_NONBLOCK without having to use a third-party open or a third-party platform-specific definition of a flag for custom_flags.

[the8472]

The open flag sounds reasonable, though in the usual unfortunate unix fashion it's overloading "don't block on open" and "open as non-blocking".

But if we're adding an open flag that is useful in some edge-cases, can we be a bit more holistic and examine which other unix-portable flags would be useful too? O_NOCTTY and O_DIRECTORY perhaps?

[joshtriplett]

But if we're adding an open flag that is useful in some edge-cases, can we be a bit more holistic and examine which other unix-portable flags would be useful too? O_NOCTTY and O_DIRECTORY perhaps?

I'm all for it, but I think each one should be a separate ACP for us to evaluate.

[the8472]

Seconded