The two main reasons (IIRC):
1. The asynchronous nature of stdout confused a lot of people, esp.
the fact that Node could exit before all console.log statements have
been printed.
2. Printing faster than stdout could handle would queue up the output
in a backlog, leading to excessive memory usage.
On a side note, stderr has always been blocking.
I asked the same question recently :
"Now a simple control-S in the terminal can grind to a halt any node.js server."
<http://groups.google.com/group/nodejs-dev/browse_thread/thread/92333182b1fd237e#>
To think that a single control-S could halt my node server makes me feel nervous.
OTOH, it's true that a control-C would be worse.
But even so...
On Mar 14, 2012, at 10:46 AM, Jorge wrote:
> Begin forwarded message:
>
>> From: Jorge Chamorro Bieling <bie...@terra.es>
>> Date: March 14, 2012 12:08:48 AM GMT+01:00
>> To: Isaac Schlueter <i...@izs.me>
>> Subject: Re: Now a simple control-S in the terminal can grind to a halt any node.js server.
>> On Mar 13, 2012, at 11:56 PM, Isaac Schlueter wrote:
>>>
>>> On Tue, Mar 13, 2012 at 15:04, Jorge Chamorro Bieling <bie...@terra.es> wrote:
>>>> Because now, it seems, that write()ing to stdout is blocking...
>>>>
>>>> For example:
>>>>
>>>> 1.- paste this in a shell:
>>>>
>>>> node << EOF
>>>> require('http').createServer(function(req, res) {
>>>> res.end("FAST");
>>>> process.stdout.write('.');
>>>> }).listen(8000);
>>>> EOF
>>>>
>>>>
>>>> 2.- and hit control-S
>>>>
>>>> 3.- then do an `ab -t 2 http://127.0.0.1:8000` in another shell, and all you'll get is :
>>>>
>>>> apr_poll: The timeout specified has expired (70007)
>>>>
>>>> Why? Because the node server is totally blocked by the control-S!
>>>>
>>>> Are you aware of that ?
>>>> Isn't that something to be concerned about ?
>>>> Why did you change write()ing to stdout to blocking ?
>>>>
>>>> Cheers,
>>>> --
>>>> Jorge.
>>
>>
>>> This API change was made quite some time ago. It prevents a lot of
>>> confusion and edge-case bugs.
>>>
>>> If it causes problems for you, please bring it up on the
>>> nodej...@googlegroups.com mailing list, where API changes can be
>>> discussed and explored from multiple angles.
>>>
>>> In the meantime, I would not recommend writing to stdout on every
>>> request if it might be blocked.
>>>
>>
>>
>> Isaac,
>>
>> It would be equally frozen whether it wrote on every request or just once.
>
> A warning, a message, anything, just a single char written to stdout could now freeze a node.js server.
> --
> Jorge.
According to the docs, POSIX signals are mapped to events. I was planning on just catching them. I assume that's how the "press ctrlC again to exit" is implemented for the REPL. Corrections?
--
Job Board: http://jobs.nodejs.org/
Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to nod...@googlegroups.com
To unsubscribe from this group, send email to
nodejs+un...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en
Some signals are. For example, you can catch Ctrl-C with
process.on('SIGINT', cb) (maybe not on Windows).
However, signals like SIGSTOP (which is what some terminals send if
you press Ctrl-S) cannot be caught.
Bummer. I never thought about that, but it makes sense now that I do. One more reason not to rely on stdin/stdout for stuff I don't want interrupted I guess.
Well and plainly spoken, Matt. I use upstart (don't even get me going on forever).
I will admit that I sometimes pound out an interactive tool out of expedience and that it would be nice to suppress some signals as a guard against my fat fingers, but that's an informed choice and not any shortcoming of POSIX, node, etc.
Right. I forgot that STOP was one of them. I almost never send a stopint. I'm a simple thinker...I use sigkill liberally. : )
I wasn't trying to practice Zen...it just happened. :)
"don't even get me going on forever" => +1k!