

Handling blocking IO in Go - BarkMore
http://www.kanwisher.com/2012/07/19/handling-blocking-io-in-go/

======
alptrv
I don't know why author thinks that blocking IO is a "One of the most
frustrating things when you start with go" because from the very beginning of
leaning Go most articles, tutorials and books tells that golang uses
goroutines to achieve concurrency. I've started learning golang a few weeks
ago and the fact that all IO is blocking was the most nicest part of the
language. I mean you dont need to wrap your code in deeply nested callbacks as
you do in node.js, and your code is always look straightforward. In fact IO is
only _looks_ blocking, AFAIK, go uses epoll/kqueue under the hood for IO
operations.

------
hasenj
Good start, but needs more explanations I think. If I was totally new I
wouldn't understand what this stuff is.

Actually, I _am_ totally new, but I've seen talks and read various tutorials,
so I can understand the concepts presented here.

I think this stuff is really important and people really should become aware
of how do handle blocking IO in Go. Maybe then people will finally realize
that things like Node (and Twisted, and Tornado, etc) are not really a good
way to handle blocking IO after all.

I'm very excited about Go, and I don't understand why it's not catching up yet
with the startup crowd.

~~~
masklinn
> If I was totally new I wouldn't understand what this stuff is.

If you were "totally new" and didn't even know about go and goroutines, why
would you even click on that link _and expect to understand what it's talking
about_?

> Maybe then people will finally realize that things like Node (and Twisted,
> and Tornado, etc) are not really a good way to handle blocking IO after all.

Wow, that's one big strawman to set on fire.

Of course evented systems "are not really a good way to handle blocking IO",
nobody's ever claimed that, quite the opposite. There's a reason why the IO
layers have to be provided by the evented runtime or patched (and replaced by
non-blocking versions) on the original one. Here's how you handle blocking IO
in an evented system: you bloody fucking don't.

For the outlined case, a node user would use child_process[0] which is non-
blocking and provides all the tools you should need (I'm sure there are
libraries out there providing an even nicer interface to sub-processes).

[0] <http://nodejs.org/api/child_process.htm>

~~~
hasenj
> If you were "totally new" and didn't even know about go and goroutines, why
> would you even click on that link and expect to understand what it's talking
> about?

That doesn't even make any sense.

You're objecting about why a person would read an introduction to a
language/platform if they're not familiar with it.

> Of course evented systems "are not really a good way to handle blocking IO",
> nobody's ever claimed that, quite the opposite.

Oh really? That's _all_ Node.js claims to do.

What's Node's tagline? "Evented I/O".

Node's only purpose is to "fix" blocking I/O.

Go on, read what the homepage says:

<http://nodejs.org/>

 _Node.js is a platform built on Chrome's JavaScript runtime for easily
building fast, scalable network applications. Node.js uses an event-driven,
non-blocking I/O model that makes it lightweight and efficient, perfect for
data-intensive real-time applications that run across distributed devices._

Notice how it doesn't sell itself as "javascript on the server side" or
anything like that.

It sells itself on two points:

\- A platform that runs on top of Google's V8 (fast)

\- It fixes I/O blockage by using events and callbacks (aka evented I/O)

In other words, it's all about scalable backend services.

If you think Node's approach is a good way to handle blocking IO, good for
you.

I happen to think it's a terrible approach. And I think there is a much more
viable alternative out there for backend developers who have performance
concerns: whether it's related to IO blockage, or the general slowness of
interpreted languages.

~~~
masklinn
> You're objecting about why a person would read an introduction to a
> language/platform if they're not familiar with it.

No, this is _not_ an introduction to a language/platform, this is an
introduction to a very specific problem/detail of a language/platform.

> Node's only purpose is to "fix" blocking I/O.

By _getting rid of it_.

> If you think Node's approach is a good way to handle blocking IO, good for
> you.

Are you trying for a daftness award?

~~~
hasenj
> Are you trying for a daftness award?

No, you are nitpicking on the word "handle". Alright, let's change that to
"deal with the problem of IO blockage". Happy now?

You know full well what I mean, and I can't interpret your attitude as
anything other than trolling.

------
drivebyacct2
Source: [https://groups.google.com/forum/?fromgroups#!topic/golang-
nu...](https://groups.google.com/forum/?fromgroups#!topic/golang-
nuts/MN_W1_oAFrs)

Not sure what the original expectation was. How else would an operation, that
by definition continuously writes to stdout until interrupted be anything
_but_ blocking... until the process was killed?

