-
Notifications
You must be signed in to change notification settings - Fork 29.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[v6.x backport] src: add environment cleanup hooks #22633
[v6.x backport] src: add environment cleanup hooks #22633
Conversation
cb.fn_(cb.arg_); | ||
cleanup_hooks_.erase(cb); | ||
// TODO(addaleax): Not calling CleanupHandles() here because it hangs in a | ||
// busy loop. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think just not doing this is a perfectly viable option. We’re not actually interested in making the Environment clean up after itself, that’s probably impossible at least for v6.x.
@gabrielschulhof The PR looks good to me, but be aware that afaik we generally don’t do |
@addaleax thanks for the review! We discussed it in @nodejs/n-api and I think we'll ask nicely for an exception so we can retain our claim that N-API version 3 is implemented across all supported versions. |
@nodejs/lts I’m adding the label for your agenda ^^^ |
v6.x is in Maintenance mode https://github.com/nodejs/Release/blob/master/README.md:
Perhaps we should start a discussion on n-api fixes/changes going into Maintenance releases? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm -1 on this change
As much as we would like to keep things up to date we can't make exceptions to our LTS or SemVer out of convenience.
There are no plans for new 6.x releases outside of a security release or major regression.
@MylesBorins this is not really about keeping things up-to-date. It is about a promise we have made and broken. We claim that "N-API version 3" is available on all maintained versions of Node.js, but these APIs are not available on v6.x. Therefore we won't really have ABI stability until v6.x is no longer maintained. The fact that the current minor release of v6.x claims to have N-API version 3 but doesn't is a bug. This is the fix. So, in that sense, this PR is not semver-minor. I would even argue that this is a critical fix because, without this fix, the whole ABI stability picture breaks down, to be restored only when v6.x becomes completely unsupported. I admit that we might have planned our strategy of introducing new N-APIs as experimental sooner, in which case these APIs would also have landed under the experimental flag, and as such, would not have been a part of the N-API version 3 promise. @nodejs/n-api it looks like one of the prerequisites of taking a new N-API out of experimental is that it be backported to all Node.js versions, so we never again run into this situation. In fact, we may have a very narrow window for getting N-APIs out of experimental because, once the oldest support Node.js goes into maintenance mode, we can not land the PR that modifies |
An alternative would be to amend our LTS policy to account for a special status of N-API. One could definitely argue that it should have such a status, being an API that is explicitly not governed by semver itself, but rather stable indefinitely. |
@addaleax I imagine that even if N-API received such a concession, our choice of which APIs to mark as no-longer-experimental would be limited to those that were backported at the time that the oldest Node.js release went into Maintenance mode, because we would endeavour to always restrict PRs against such a release to re-shufflings of the order of things in |
ok with this landing as semver-patch
Let's land this as semver-patch and consider it a bug fix. If the contract of n-api is consistency across all versions we should be suporting it as such. That being said I have mixed feelings about n-api having been declared as stable with changes like this landing afterwards... but this isn't the issue to debate that. There are a couple of patches on 6.x-staging right now, including one that landed today for a breakage in BSD that we should get a release out for soon... let's land this and include it in an upcoming release. Should we audit n-api and ensure that nothing else should land? |
@MylesBorins I'll have a look at the diff between master and this branch. There should be no more new APIs, because everything else should be behind |
diff -u \
<(git show master:src/node_api.h | \
sed -r 's/(napi_[a-zA-Z_]+)/\n\1\n/g' | \
grep '^napi_' | sort -u) \
<(git show backport-19377-to-v6.x:src/node_api.h | \
sed -r 's/(napi_[a-zA-Z_]+)/\n\1\n/g' | \
grep '^napi_' | sort -u) | \
less shows only references to There are internal changes we could backport, like the fairly significant performance fix e41ccd4 but we need to decide if that's worth the churn. |
+1 for landing, and if landing as a bug fix is the way to do that then sounds good to me. |
@MylesBorins should I backport the perf fix from e41ccd4? |
I'm apprehensive about backporting perf fixes but I defer to @mhdawson on this one Perhaps, as suggested above, we should come up with a unique LTS policy specifically for n-api... as it working exactly the same on all branches is a huge part of the contract |
I would not backport e41ccd4 unless commits start to depend on it. |
I agree with deferring the backport of e41ccd4 |
Added |
The original PR was semver-minor and we had decided for the 8.x napi PR to land it a similar change as semver-minor so I'm adding back the label. Since 6.x is EOL in less than 3 months I think we are too late on doing this. As I mentioned a couple of months ago I would like to see us come up with an explicit process around n-api if we are going to want to land things in maintenance. My gut it we have missed the boat for 6.x, but I'm open to debate on this in the next release meeting |
@MylesBorins are we planning a 6.x release for any other reasons. I agree that since we are so close to EOL the decision to land should be re-discussed in the next meeting. We might want to invite @gabrielschulhof so that he can be included in the discussion on the potential impact. |
@gabrielschulhof, this seems to be failing on osx in CI with the following error
|
I suspect this is because |
Would it be okay to add |
This adds pairs of methods to the `Environment` class and to public APIs which can add and remove cleanup handlers. Unlike `AtExit`, this API targets addon developers rather than embedders, giving them (and Node’s internals) the ability to register per-`Environment` cleanup work. We may want to replace `AtExit` with this API at some point. Many thanks for Stephen Belanger for reviewing the original version of this commit in the Ayo.js project. Refs: ayojs/ayo#82 PR-URL: nodejs#19377 Reviewed-By: Ben Noordhuis <[email protected]> Reviewed-By: James M Snell <[email protected]>
f3236f2
to
54c268e
Compare
@addaleax I made the change you suggested. |
@addaleax looks like there are more problems once we use |
@addaleax looks like we might need a later compiler than what we're using. |
@gireeshpunathil Yeah, sorry, I think the issue is that I’m happy to implement that if you want. (Also, the perf difference between |
@addaleax please, and thank you! |
This adds pairs of methods to the
Environment
class and to public APIswhich can add and remove cleanup handlers.
Unlike
AtExit
, this API targets addon developers rather thanembedders, giving them (and Node’s internals) the ability to register
per-
Environment
cleanup work.We may want to replace
AtExit
with this API at some point.Many thanks for Stephen Belanger for reviewing the original version of
this commit in the Ayo.js project.
Refs: ayojs/ayo#82
PR-URL: #19377
Checklist
make -j4 test
(UNIX), orvcbuild test
(Windows) passes