Revert "src: fix stuck debugger process"

[bnoordhuis]

Refs: #2778

/cc @viirya

CI: https://ci.nodejs.org/job/node-test-pull-request/648/

[evanlucas]

@bnoordhuis mind explaining the revert and where the regression is?

[bnoordhuis]

It's in the commit log, let me know if it's not clear enough:

Reverted for breaking node --debug-brk -e 0. It should immediately quit but instead it hangs now.

The regression is that the uv_async_t debug handle is not unref'd when --debug-brk is specified. I want to revert first instead of trying to fix it because the commit is lined up for the next LTS release.

[jasnell]

Yep, thanks for catching that @bnoordhuis. Fortunately the commit is only in staging and hasn't yet been landed in the v4.x branch so I'll simply pull it from the list of commits that I land in v4.x today.

[evanlucas]

Ah sorry missed that. LGTM if CI is happy

[jasnell]

LGTM

[viirya]

Not sure about this. Correct me if I am wrong. But shouldn't --debug-brk break before the first statement? Why it should return immediately when running with --debug-brk=1234 -e 0.

[bnoordhuis]

Maybe --debug-brk was a bad example but for example node --debug -e 0 had the same issue. If you file an issue we can look into changing --debug-brk because I think the intended behavior is for it to wait until a debug client connects.

The thing is though that ff877e9 introduced an unintentional change. If we decide to change how --debug-brk behaves in stable and LTS it should be intentional and documented. In that light I think the revert is justified.

[bnoordhuis]

For proactivity's sake: #3589

[jasnell]

Landed in v4.x-staging in 5e6f7c9. No need to land in v4.x because the original commit hadn't landed there yet.