runtime: poller should be used for file system operations

[lexprfuncall]

Presently, the runtime blocks an operating system thread when performing a file system
operation such as a file read or write.  However, the same interfaces used by the poller
to poll socket file descriptors can be used for file system file descriptors.

In addition to limiting the number of threads in the runtime, there are other potential
resource usage and running time benefits.  An experiement should be conducted across the
various supported platforms to understand whether there is an opportunity for a
performance improvement.  The answer might depend on the quality of the underlying
asynchronous I/O implementation and its interaction with the kernel event notification
system.

[dvyukov]

Comment 1:

Labels changed: added priority-later, go1.3maybe, removed priority-triage, go1.2maybe.

[dvyukov]

Comment 2:

FTR, there was a request to expose the poller as a standard package (e.g. os/poll).

[dvyukov]

Comment 3:

Windows should be the simplest OS to try, sockets and files are the same with respect to
polling. And it also has good async IO implementation.

[alberts]

Comment 4:

I requested os/poll long ago.
It would really help with dealing with the file descriptor returned by
ibv_create_comp_channel when writing InfiniBand/RDMA code with libibverbs.
There are probably a few other userspace/kernel interfaces that do similar things.

[dvyukov]

Comment 5:

There is a possibility to associate existing fd with os.File. If we make
os.File.Read/Write "non-blocking", will it be enough for your use case?

[rsc]

Comment 6:

What kinds of files are we talking about? Historically pollers have only worked on
network socket fds, not on file system files.

[dvyukov]

Comment 7:

We are talking about normal files of local hard drive.
In windows world one can do async IO with any kind of IO HANDLE.
I don't know what's the status of async file IO on linux. AIO is probably still broken.
This page https://code.google.com/p/kernel/wiki/AIOUserGuide says that epoll should
work, but a simple test shows that it does not.

[davecheney]

Comment 8:

My 2 cents: I don't see much value in AIO for operations on block devices, but if
integrating the runtime poller would allow concurrent Read/Write and Close operations
above what POSIX semantics provides on file/pipe/char fds (similar to what we have on
net fds), I see that as a valuable addition.

[rsc]

Comment 9:

Labels changed: added release-none, removed go1.3maybe.

[rsc]

Comment 10:

Labels changed: added repo-main.

[gopherbot]

Comment 11 by tank.en.mate:

This code seems to integrate Linux kernel AIO (as opposed to POSIX aio) with epoll. It
also appears to integrate signal handling via epoll as well for what it's worth.
http://marc.info/?l=linux-aio&m=129646725201847

[jaracil]

Here is a nice implementation of Poller:
https://github.com/npat-efault/poller

It gives safe Close() in one goroutine while read/write operations are blocked in other goroutines and all read/write operations are released after close().
It also gives useful methods like SetDeadline, SetReadDeadline, SetWriteDeadline.

This package only implements linux epoll syscall. I think it could use golang runtime poller to make it multi platform.

Thanks.

[ianlancetaylor]

I think that on tip this one is now done as much as it can be. Closing.

[t3rm1n4l]

Is there any possibility for future runtime poller support for file I/O ?

[davecheney]

@t3rm1n4l

Please don't comment on closed issues. Unlike many projects on GitHub, the Go project does not use its bug tracker for general discussion or asking questions. We only use our bug tracker for tracking bugs and tracking proposals going through the Proposal Process.

Please see https://golang.org/wiki/Questions for good places to ask questions.

Is there any possibility for future runtime poller support for file I/O ?

The limitation is the operating systems Go supports do not have good APIs for async file i/o. This isn't a complete answer, I know there is some kind of async i/o on linux, windows probably has something related to overlapping file operations or i/o completion ports (or something)--i've no idea what it would take for osx, freebsd, et al.

The take away is it might be possible to support async file io for a subset of platforms, but it's nowhere near as straight forward as the support for async network io, and it would/will take an expert in each platform to implement it.