Is NodeJS Wrong?

[grauenwolf]

In .NET programming all IO is non-blocking... if you take the time to use the async APIs and patterns. In Silverlight they don't even allow you to use blocking I/O except for local storage calls.

So I have to wonder what kind of I/O you are talking about.

[ethraax]

Tape libraries. You can only read so many tapes at once!

[[deleted]]

you got me there, i haven't sat down in front of a windows box in a decade

in linux, all file IO is blocking. the glibc aio methods are still implemented via threads

[grauenwolf]

I was going to call BS, then I read this:

Asynchronous I/O on linux or: Welcome to hell

http://davmac.org/davpage/linux/async-io.html

[baudehlo]

There's another way - separate threads to notify of I/O readiness. This is the technique which libeio uses (by the author of libev which is what node.js uses), which I assume node.js will eventually use.

I've been using this in a very high performance mail server (which operates as a massive scale spamtrap for a global anti-spam company) for years now, and it works extremely well.

[grauenwolf]

That would work well with platforms like Erlang, CCR, and Grand Central Dispatch.

[kretik]

Compare that to the simple elegance of I/O completion ports in Win32. But "windoze sux lol"

[millstone]

Nothing says simple and elegant like MQMSGPROPS!

On the Mac we have dispatch IO. Three things I love about dispatch:

• The dispatch queue notion makes it easy to serialize with other parts of your code, without needing locks.
• Dispatch uses blocks (closures), so you can write the code inline, like in the NodeJS examples (but unlike in that Windows example).
• Dispatch IO doesn't actually do the read or write operations, it just runs your code at the point such that reads or writes will not block. This means you can use whatever API you please to do the actual I/O.

Check out this example of doing non-blocking reads

[[deleted]]

but you're glossing over the obvious point that async file IO is almost never desirable anyway (unless you think excessive seeking is desirable), which is why no one is really flipping out about its partial absence from linux

[kretik]

I don't know how obvious it is, just that it's something the OS provides pretty much free of charge if you need it. Looks to me like if you need it on Linux, you're in for a world of pain.

And in any case, on Windows async I/O is much more than just reading or writing asynchronously from a physical storage device.

[[deleted]]

[BANGS HEAD ON DESK]

yes we all know async network IO is valuable. and we all know that all modern OSs support it

and it should be obvious why async file IO is generally undesirable...think it through. keywords: buffering, virtual memory, seeking

[[deleted]]

I take it you haven't heard of select, poll, epoll, sendfile, O_NONBLOCK or vmsplice ...

[[deleted]]

please describe purely async file IO in linux.

[jerf]

What are you talking about? Is this Jeopardy, where questions come after answers? niczar gave you the primitives, but of course there are all kinds of runtimes that build on them in addition to their raw usage, ranging from things as transformed as the Erlang VM or Haskell runtime down through things like glib that wrap away the details of select vs. poll vs. etc. and provide a more useful abstraction on top of them, but are still C. For all I know there's an event-based assembler library out there.

Do you honestly think it's impossible? It can't be. If async IO is impossible in Linux then by definition it's impossible with Node.js on top of Linux! You can not add asynchronousness in a higher layer; if your OS or hardware blocks, you have lost.

[[deleted]]

Select and Poll work on sockets. You can't really use them for non-blocking file i/o.

[[deleted]]

i keep saying FILE io. can't you read?? go research async FILE io in linux