Are there plans to support context for file operations, specifically cancellation?

Use case: FUSE filesystem server, implemented using underlying files which may be remote (as in NFS etc) or just slow (disk spun down or IO errors), kernel can cancel FUSE requests at any time, including based on end user control-C.

Use case 2: HTTP static file serving, similar scenarios.

@tv42 I'm certainly open to it but I don't understand how to implement it efficiently.

@ianlancetaylor Heh, I hoped it would have somehow followed from deadlines.

Not sure, whether this is the right place to ask (I've mentioned that idea in #22100), but since we have already internal/poll, is it possible to also have (in addition to the Deadline methods above) a io.File method that has prototype similar to:

Async() <-chan int

This method will make read/write on io.File non-blocking and returns a notification channel (int type could be some concrete type of io package).

Where the channel is used to receive notifications, like: FD is ready to read/is closed (or just close(channel)).

That need comes naturally, if you look at my current workaround with sigio approach (and syscalls): https://play.golang.org/p/k5R8RcMPwg

@juliandroid From your code it looks like you basically want an interruptible read. You can get that using the SetReadDeadline in this proposal. Combine that with a goroutine doing the read and sending the results on a channel, and I think you have everything you want.

Set a deadline of one minute and start a goroutine that reads from the TTY and sends the data over the channel. Handle your small timeout in a goroutine that reads from a timer channel and from the TTY read channel.

Yes, your Async suggestion can be useful, but it requires a lot of mechanism, it will be used very very rarely, and the operations that it supports can be done without it.

In any case this proposal is about the deadline methods.

I think you are mostly correct, although in some cases, I might be more interested in performance then I have to set bigger timeout and then lose flexibility to terminate the goroutine quickly.
If I set the timeout to some very small value then I have to do a lot of read calls unnecessary.
Both combined seems best approach.

One way to mitigate the issue is by passing second optional argument to the Set(Read)Deadline.
I.e. to have one argument with bigger timeout value that is the maximum timeout for whole read to complete and one argument that is a SoftTimeout that will interrupt the Read() operation only if the read buffer is empty. In other words, If there are still bytes coming, in less than SoftTimeout ms then Read() continues to deliver bytes. Every time you get data in less than SoftTimeout you have again another SoftTimeout for the next batch of bytes until EOF, close() or the global timeout expires.

Maybe it is a bit too complicated, although logical and maybe faster :)

What you are looking for is the termios VMIN and VTIME values.

Let's keep this issue about the proposed deadline methods.

SGTM. I'm assuming they will return a non-nil error for non-pollable files.

Change https://golang.org/cl/71751 mentions this issue: internal/poll: always decref if setting deadline fails

Change https://golang.org/cl/71770 mentions this issue: os: add deadline methods for File type

Change https://golang.org/cl/71973 mentions this issue: runtime: for kqueue treat EVFILT_READ with EV_EOF as permitting a write