src: emit 'beforeExit' event on process object

[bnoordhuis]

Unlike the 'exit' event, this event allows the user to schedule more
work and thereby postpone the exit. That also means that the
'beforeExit' event may be emitted many times, see the attached test
case for an example.

Refs #6305.

TODO: Still needs documentation.
Suggested reviewers: @tjfontaine @sam-github

[sam-github]

There's no docs, is this intended to be not-for-use-by-the-public?

There is no test that process.exit() cannot be trapped and ignored via this event, something that came up in review of #5583, see test/simple/test-beforeexit-event-exit.js

Its not clear due to lack of docs and above test whether this is functionally identical to #5583, with code restructured to your preferences, or whether it differs slightly in function.

[bnoordhuis]

There's no docs, is this intended to be not-for-use-by-the-public?

See the TODO in the description: TODO: Still needs documentation.

There is no test that process.exit() cannot be trapped and ignored via this event

I added another test.

Its not clear due to lack of docs and above test whether this is functionally identical to #5583, with code restructured to your preferences, or whether it differs slightly in function.

It's the same thing but it a) applies to the current HEAD, and b) doesn't require changes to libuv.

[tjfontaine]

I'm still +1 on this idea, and agree with most of what I said in #5583 (comment) and @sam-github's initial documentation is quite a good start for this, I vote we just include it in your commit

I am not sure if maybe in addition to the exitCode we should also provide a state counter indicating the number of times the loop has been resurrected, since it seems like a common pattern for consumers and useful state to have when debugging.

[bnoordhuis]

I am not sure if maybe in addition to the exitCode we should also provide a state counter indicating the number of times the loop has been resurrected

Never cement in the API what the user can (easily) keep track of herself.

Stealing^Wincluding Sam's documentation is a good idea, I'll add it.

[tjfontaine]

It's not necessarily fool proof to keep track of this by yourself, because (oh god why would I say this) someone could load another module which also watches and then there's two opinions on how many times this has happened, even if we don't expose it to the callback I think keeping the state is a good idea

[sam-github]

@bnoordhuis ok, should I close the other PR, or will you?

[trevnorris]

I'm a little behind on the implementation, and I'm probably missing
something, but I'm assuming if there are two callbacks assigned then both
will get called. And two different counters in two different scopes
incrementing when their callbacks are called should always have the same
result.

[tjfontaine]

Having within scope the expected value is not the same thing as being
able to check the state from a global when debugging a process

[trevnorris]

If we insist on implementing this, please do so by setting a counter (e.g.
size_t) in env.h and setting a getter for JS. This is a value that won't be
accessed much and that approach will have the least performance impact.

[indutny]

Thank you, landed in a2eeb43