Handling blocking IO in Go

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

by BarkMore • 14 years ago

28 8 14 years ago

hasenj3• 14 years ago

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.

masklinn2• 14 years ago

> 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

hasenj3• 14 years ago

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

slurgfest• 14 years ago

I found this post to be extremely, gratuitously aggressive and pointed, completely out of proportion to hasenj's. Nor is this the kind of social issue I expect to drive this kind of instant hot anger. Even if he is completely wrong, that isn't necessary.

I didn't learn anything about node's technical side but I did learn something about the community side

alptrv• 14 years ago

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.

drivebyacct2• 14 years ago

Source: https://groups.google.com/forum/?fromgroups#!topic/golang-nu...

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?

Handling blocking IO in Go

Related Stories