felixge2

You're correct, it would not be impossible to write coroutine safe code in node.js.

The problem is just that coroutines are not natural in JS, and people will shoot themselves in the foot all the time.

Some "features" are better left out to allow a bigger audience to write reliable Software. Your milage may vary.

Well, it's not a big problem - you should have a timeout on incoming connections, and node is pretty well-suited for having lots of "hanging" connections (I ran some test with 56k active connections).

If a connection is closed, either by a timeout, or EOF, you simply check if the promised content length matches the count of received bytes - if not you should probably discard the whole thing (unless you're specifically supporting broken clients).

Yes, other languages might be more suitable for coroutines.

But then again, Erlang is probably a language more "suitable" to high concurrency programming, but node's goal is to make writing scalable networks programs possible for everyone. One might call it the PHP of concurrency : )

Well, just as there is the problem of thread-safety, there is also the problem of co-routine safety.

Basically callbacks and coroutines don't play well together.

But there were a bunch of reasons for the removal, performance and quality of the initial implementation also played into it AFAIK.

This presentation has a tiny bit on coroutines:

http://nodejs.org/jsconf2010.pdf

> Coroutines complicate the mental model while adding only cheap syntactic pleasures.

You could still do that if the length was pre-announced, or am I missing something?

I think the reason multipart works that way, is so you can stream data that you don't know the full length of beforehand.

But afaik, that's pretty much never the case with file uploads, unless you are uploading a file that is still growing in size - so yeah, it's annoying : ).

('felixge2' because my other account is in noprocrast mode: )