On Fri, 12 Dec 2014 03:24:15 -0800 (PST) Manlio Perillo wrote:
Unfortunately async I/O is not supported by Go, AFAIK.
Go doesn't support async I/O because it's never necessary with Go.
It is not necessary but it is desiderable, when async I/O is
implemented (correctly) in the kernel. The reason is efficiency.
For the same reason the net package (an only the net package, for
reasons I'm not sure to fully understand) uses a poller,
Just a guess, but I'm pretty confident that it's valid at least to some
I have extensively worked with Tcl which had in-core event-driven I/O
long before all the other popular solutions touting this idea as novel
came to existence (like Python's Twisted, Node.js etc). The point of
interest of the Tcl's approach to this is that you are able to set up
event-driven I/O on any "channel", which, in Tcl's parlance, is
something on which you can do I/O -- be it a file or an UDP endpoint or
a TCP socket and basically everything on which you can do read() and/or
write() down at the kernel level. So you can open a regular file to get
a channel then set event driven I/O on it and then, say, try to read the
whole file using "data is ready" callbacks.
And then in the case of regular files you imminently hit a
well-observable problem: no matter if you read or write a file, its
data is "instantly ready", so the matching events basically congest the
event loop making other users of it (sockets, Tk GUI events -- these
also use the main Tcl event loop) starve or blocked. In other words,
the data in normal files are "too ready" to be efficiently operated by
an event loop which also processes the sources of data with "normal
readiness", such as network sockets. This effect led to the necessity
of using clever but ugly hacks which basically pushed the "data ready"
events originated from file channels to the back of the event loop as
events of class "idle".
I think that's basically the reason why Go sort-of assumes the most
common case: doing the read() or write() syscalls against non-sockets
will see the instant availability of data and hence the syscalls won't
block. That could explain why the poller is used for sockets only.
I don't know how much overhead would async I/O incur. Supposedly not
so much, so having it in the runtime (and not exposed) would be just the
right thing -- allowing not to fork OS threads on stalled blocking
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to email@example.com.
For more options, visit https://groups.google.com/d/optout.