Add hint on infinite loops.

[mk-pmb]

No description provided.

[myndzi]

When binding SIGINT, Node's ability to interrupt infinite loops goes away. I've published a new version that should take care of this by means of a watchdog process. You can use Ctrl+C twice to exit an infinitely looping process, but you won't be able to gather any information from it since it is forcefully killed.

[mk-pmb]

When binding SIGINT, Node's ability to interrupt infinite loops goes away.

I hope that¹ can be improved for .once() handlers. -> node issue #9050

Edit: ¹ "that" = node's inability to interrupt loops when listening to (one) SIGINT. Relevant part of the other thread is my 2nd post ("Now for my real reason I'm here." …) and potential follow-up. I added the anchor to the link.

[myndzi]

Please note that wtfnode is a debugging tool, it's not meant to be used all the time, especially not in production. The fact that a program couldn't be ended in an infinite loop while running under wtfnode was a definite problem, but trying to implement/simulate some robust generic wrapping behavior is a different thing altogether. The purpose of the fix to this issue was to enable the user to terminate a script, not to provide a generic solution to the problem you linked.

The patch I made here doesn't actually execute the code in your script's SIGINT handler, because v8 can't do that. If it's in an infinite synchronous loop, no other code can run -- whether it's a recurrent .on handler or a one-off .once handler. wtfnode isn't fixing this problem, it's only dealing with the consequences.

I suspect that, to get the behavior you want, you'll need your own wrapper, so the process tree would be like:

wtfnode

• your wrapper (with the once handler?)
  -- your actual script

It might be possible to provide some sort of api to let you register sigint (or, in general, signal handlers) with wtfnode to execute on your behalf, but I think that functionality is probably out of scope for wtfnode.

What would you like to see happen?

[myndzi]

P.S. I wouldn't be averse to maybe publishing some kind of generic signal handler wrapper thing that wtfnode could depend on, but I'm not sure it's worth it :) It's probably better to write node programs like node programs and not C programs...

[mk-pmb]

Sorry for the confusion. I did not mean to request any change in wtfnode. In the other thread, after giving advice about the program structure, I questioned a node UX problem related to the SIGINT blocking, and meant to notify the subscribers of this issue because I thought they might be interested whether the SIGINT handling changes.

[myndzi]

Ah, I see! Thanks.