Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

runtime: poller should be used for file system operations #6222

Closed
lexprfuncall opened this issue Aug 22, 2013 · 15 comments
Closed

runtime: poller should be used for file system operations #6222

lexprfuncall opened this issue Aug 22, 2013 · 15 comments

Comments

@lexprfuncall
Copy link

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
Copy link
Member

dvyukov commented Aug 22, 2013

Comment 1:

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

@dvyukov
Copy link
Member

dvyukov commented Aug 22, 2013

Comment 2:

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

@dvyukov
Copy link
Member

dvyukov commented Aug 22, 2013

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
Copy link
Contributor

alberts commented Aug 22, 2013

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
Copy link
Member

dvyukov commented Aug 23, 2013

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
Copy link
Contributor

rsc commented Sep 3, 2013

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
Copy link
Member

dvyukov commented Sep 3, 2013

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
Copy link
Contributor

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
Copy link
Contributor

rsc commented Dec 4, 2013

Comment 9:

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

@rsc
Copy link
Contributor

rsc commented Dec 4, 2013

Comment 10:

Labels changed: added repo-main.

@gopherbot
Copy link
Contributor

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
Copy link

jaracil commented Jun 4, 2015

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
Copy link
Member

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

@t3rm1n4l
Copy link

t3rm1n4l commented Oct 6, 2017

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

@davecheney
Copy link
Contributor

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

@golang golang locked and limited conversation to collaborators Oct 6, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

9 participants