Skip to content
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

n-api: defer Buffer finalizer with SetImmediate #28082

Closed
wants to merge 2 commits into from

Conversation

addaleax
Copy link
Member

@addaleax addaleax commented Jun 5, 2019

src: fix off-by-one error in native SetImmediate

Previously, the throwing callback would have been re-executed in case
of an exception. This patch corrects the calculation to exclude the
callback.

n-api: defer Buffer finalizer with SetImmediate

We have a test that verifies that JS execution from the Buffer
finalizer is accepted, and that errors thrown are passed
down synchronously.

However, since the finalizer executes during GC, this is behaviour is
fundamentally invalid and, for good reasons, disallowed by the
JS engine. This leaves us with the options of either finding a way
to allow JS execution from the callback, or explicitly forbidding it on
the N-API side as well.

This commit implements the former option, since it is the more
backwards-compatible one, in the sense that the current situation
sometimes appears to work as well and we should not break that
behaviour if we don’t have to, but rather try to actually make it
work reliably.

Since GC timing is largely unobservable anyway, this commit moves
the callback into a SetImmediate(), as we do elsewhere in the code,
and a second pass callback is not an easily implemented option,
as the API is supposed to wrap around Node’s Buffer API.
In this case, exceptions are handled like other uncaught exceptions.

Two tests have to be adjusted to account for the timing difference.
This is unfortunate, but unavoidable if we want to conform to the
JS engine API contract and keep all tests.

Fixes: #26754 (as far as the non-build part is concerned)

@nodejs/n-api

Checklist
  • make -j4 test (UNIX), or vcbuild test (Windows) passes
  • tests and/or benchmarks are included
  • commit message follows commit guidelines

Previously, the throwing callback would have been re-executed in case
of an exception. This patch corrects the calculation to exclude the
callback.
We have a test that verifies that JS execution from the Buffer
finalizer is accepted, and that errors thrown are passed
down synchronously.

However, since the finalizer executes during GC, this is behaviour is
fundamentally invalid and, for good reasons, disallowed by the
JS engine. This leaves us with the options of either finding a way
to allow JS execution from the callback, or explicitly forbidding it on
the N-API side as well.

This commit implements the former option, since it is the more
backwards-compatible one, in the sense that the current situation
sometimes appears to work as well and we should not break that
behaviour if we don’t have to, but rather try to actually make it
work reliably.

Since GC timing is largely unobservable anyway, this commit moves
the callback into a `SetImmediate()`, as we do elsewhere in the code,
and a second pass callback is not an easily implemented option,
as the API is supposed to wrap around Node’s `Buffer` API.
In this case, exceptions are handled like other uncaught exceptions.

Two tests have to be adjusted to account for the timing difference.
This is unfortunate, but unavoidable if we want to conform to the
JS engine API contract and keep all tests.

Fixes: nodejs#26754
@addaleax addaleax added node-api Issues and PRs related to the Node-API. lts-watch-v8.x labels Jun 5, 2019
@nodejs-github-bot

This comment has been minimized.

@nodejs-github-bot
Copy link
Collaborator

nodejs-github-bot commented Jun 6, 2019

CI: https://ci.nodejs.org/job/node-test-pull-request/23684/ (:white_check_mark:)

@addaleax
Copy link
Member Author

addaleax commented Jun 9, 2019

@nodejs/n-api PTAL

@addaleax addaleax added the review wanted PRs that need reviews. label Jun 10, 2019
Copy link
Member

@mhdawson mhdawson left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM this looks like a good solution as I agree that code should not be depending on the timing of when a finalizer is run.

@mhdawson
Copy link
Member

@addaleax addaleax removed the review wanted PRs that need reviews. label Jun 14, 2019
@addaleax
Copy link
Member Author

Landed in fb4d528 3ca0df2

@addaleax addaleax closed this Jun 14, 2019
@addaleax addaleax deleted the napi-buffer-finalize branch June 14, 2019 11:03
addaleax added a commit that referenced this pull request Jun 14, 2019
Previously, the throwing callback would have been re-executed in case
of an exception. This patch corrects the calculation to exclude the
callback.

PR-URL: #28082
Fixes: #26754
Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>
Reviewed-By: Gabriel Schulhof <gabriel.schulhof@intel.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
addaleax added a commit that referenced this pull request Jun 14, 2019
We have a test that verifies that JS execution from the Buffer
finalizer is accepted, and that errors thrown are passed
down synchronously.

However, since the finalizer executes during GC, this is behaviour is
fundamentally invalid and, for good reasons, disallowed by the
JS engine. This leaves us with the options of either finding a way
to allow JS execution from the callback, or explicitly forbidding it on
the N-API side as well.

This commit implements the former option, since it is the more
backwards-compatible one, in the sense that the current situation
sometimes appears to work as well and we should not break that
behaviour if we don’t have to, but rather try to actually make it
work reliably.

Since GC timing is largely unobservable anyway, this commit moves
the callback into a `SetImmediate()`, as we do elsewhere in the code,
and a second pass callback is not an easily implemented option,
as the API is supposed to wrap around Node’s `Buffer` API.
In this case, exceptions are handled like other uncaught exceptions.

Two tests have to be adjusted to account for the timing difference.
This is unfortunate, but unavoidable if we want to conform to the
JS engine API contract and keep all tests.

Fixes: #26754

PR-URL: #28082
Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>
Reviewed-By: Gabriel Schulhof <gabriel.schulhof@intel.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
BridgeAR pushed a commit that referenced this pull request Jun 17, 2019
Previously, the throwing callback would have been re-executed in case
of an exception. This patch corrects the calculation to exclude the
callback.

PR-URL: #28082
Fixes: #26754
Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>
Reviewed-By: Gabriel Schulhof <gabriel.schulhof@intel.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
BridgeAR pushed a commit that referenced this pull request Jun 17, 2019
We have a test that verifies that JS execution from the Buffer
finalizer is accepted, and that errors thrown are passed
down synchronously.

However, since the finalizer executes during GC, this is behaviour is
fundamentally invalid and, for good reasons, disallowed by the
JS engine. This leaves us with the options of either finding a way
to allow JS execution from the callback, or explicitly forbidding it on
the N-API side as well.

This commit implements the former option, since it is the more
backwards-compatible one, in the sense that the current situation
sometimes appears to work as well and we should not break that
behaviour if we don’t have to, but rather try to actually make it
work reliably.

Since GC timing is largely unobservable anyway, this commit moves
the callback into a `SetImmediate()`, as we do elsewhere in the code,
and a second pass callback is not an easily implemented option,
as the API is supposed to wrap around Node’s `Buffer` API.
In this case, exceptions are handled like other uncaught exceptions.

Two tests have to be adjusted to account for the timing difference.
This is unfortunate, but unavoidable if we want to conform to the
JS engine API contract and keep all tests.

Fixes: #26754

PR-URL: #28082
Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>
Reviewed-By: Gabriel Schulhof <gabriel.schulhof@intel.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
@BridgeAR BridgeAR mentioned this pull request Jun 17, 2019
targos pushed a commit that referenced this pull request Jun 18, 2019
Previously, the throwing callback would have been re-executed in case
of an exception. This patch corrects the calculation to exclude the
callback.

PR-URL: #28082
Fixes: #26754
Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>
Reviewed-By: Gabriel Schulhof <gabriel.schulhof@intel.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
targos pushed a commit that referenced this pull request Jun 18, 2019
We have a test that verifies that JS execution from the Buffer
finalizer is accepted, and that errors thrown are passed
down synchronously.

However, since the finalizer executes during GC, this is behaviour is
fundamentally invalid and, for good reasons, disallowed by the
JS engine. This leaves us with the options of either finding a way
to allow JS execution from the callback, or explicitly forbidding it on
the N-API side as well.

This commit implements the former option, since it is the more
backwards-compatible one, in the sense that the current situation
sometimes appears to work as well and we should not break that
behaviour if we don’t have to, but rather try to actually make it
work reliably.

Since GC timing is largely unobservable anyway, this commit moves
the callback into a `SetImmediate()`, as we do elsewhere in the code,
and a second pass callback is not an easily implemented option,
as the API is supposed to wrap around Node’s `Buffer` API.
In this case, exceptions are handled like other uncaught exceptions.

Two tests have to be adjusted to account for the timing difference.
This is unfortunate, but unavoidable if we want to conform to the
JS engine API contract and keep all tests.

Fixes: #26754

PR-URL: #28082
Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>
Reviewed-By: Gabriel Schulhof <gabriel.schulhof@intel.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
node-api Issues and PRs related to the Node-API.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

node-api/test_exception fails in debug mode
6 participants