2017-03-20 14:55:26 -07:00
|
|
|
'use strict';
|
2021-01-30 21:08:48 +01:00
|
|
|
// Flags: --expose-gc --no-concurrent-array-buffer-sweeping
|
2017-03-20 14:55:26 -07:00
|
|
|
|
|
|
|
|
const common = require('../../common');
|
2018-01-23 21:49:25 +11:00
|
|
|
const binding = require(`./build/${common.buildType}/test_buffer`);
|
2017-03-20 14:55:26 -07:00
|
|
|
const assert = require('assert');
|
2020-05-09 06:41:58 +02:00
|
|
|
const tick = require('util').promisify(require('../../common/tick'));
|
2017-03-20 14:55:26 -07:00
|
|
|
|
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: https://github.com/nodejs/node/issues/26754
PR-URL: https://github.com/nodejs/node/pull/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>
2019-06-05 23:29:18 +02:00
|
|
|
(async function() {
|
|
|
|
|
assert.strictEqual(binding.newBuffer().toString(), binding.theText);
|
|
|
|
|
assert.strictEqual(binding.newExternalBuffer().toString(), binding.theText);
|
|
|
|
|
console.log('gc1');
|
|
|
|
|
global.gc();
|
|
|
|
|
assert.strictEqual(binding.getDeleterCallCount(), 0);
|
2020-05-09 06:41:58 +02:00
|
|
|
await tick(10);
|
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: https://github.com/nodejs/node/issues/26754
PR-URL: https://github.com/nodejs/node/pull/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>
2019-06-05 23:29:18 +02:00
|
|
|
assert.strictEqual(binding.getDeleterCallCount(), 1);
|
|
|
|
|
assert.strictEqual(binding.copyBuffer().toString(), binding.theText);
|
2017-03-20 14:55:26 -07:00
|
|
|
|
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: https://github.com/nodejs/node/issues/26754
PR-URL: https://github.com/nodejs/node/pull/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>
2019-06-05 23:29:18 +02:00
|
|
|
let buffer = binding.staticBuffer();
|
|
|
|
|
assert.strictEqual(binding.bufferHasInstance(buffer), true);
|
|
|
|
|
assert.strictEqual(binding.bufferInfo(buffer), true);
|
|
|
|
|
buffer = null;
|
|
|
|
|
global.gc();
|
|
|
|
|
assert.strictEqual(binding.getDeleterCallCount(), 1);
|
2020-05-09 06:41:58 +02:00
|
|
|
await tick(10);
|
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: https://github.com/nodejs/node/issues/26754
PR-URL: https://github.com/nodejs/node/pull/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>
2019-06-05 23:29:18 +02:00
|
|
|
console.log('gc2');
|
|
|
|
|
assert.strictEqual(binding.getDeleterCallCount(), 2);
|
2024-02-23 17:50:07 +01:00
|
|
|
|
|
|
|
|
// To test this doesn't crash
|
|
|
|
|
binding.invalidObjectAsBuffer({});
|
2024-10-11 18:21:57 +03:00
|
|
|
|
|
|
|
|
const testBuffer = binding.bufferFromArrayBuffer();
|
|
|
|
|
assert(testBuffer instanceof Buffer, 'Expected a Buffer');
|
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: https://github.com/nodejs/node/issues/26754
PR-URL: https://github.com/nodejs/node/pull/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>
2019-06-05 23:29:18 +02:00
|
|
|
})().then(common.mustCall());
|
