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

⚡️ Remove artificial 4ms nextTick() delay when running in a browser #647

Merged
merged 1 commit into from
Apr 2, 2024
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 2 additions & 0 deletions .mocharc.yml
Original file line number Diff line number Diff line change
Expand Up @@ -2,3 +2,5 @@ reporter: spec
check-leaks: true
recursive: true
file: test/setup.js
globals:
- MessageChannel # Set/unset to test nextTick()
15 changes: 13 additions & 2 deletions lib/util.js
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

To discuss: we can do this, but should we do it?

The 4ms is probably in the standard for some reason, but I don't really know what. Presumably the original goal was to prevent CPU starvation, but I don't know why you would decree an arbitrary 4ms, and not just say that the time can't be guaranteed (and then it should be up to the vendor to defer event loop tasks if it needs to do other browsery things like repaint, etc.).

I note that Safari isn't standards-compliant (shocker), and doesn't actually seem to enforce this minimum time, so clearly someone thinks it's not too important to wait for this time.

I acknowledge that my proposed use-case is for tests, and maybe shouldn't impact Production-grade code.

One potential option is to add a flag that can select a nextTick() method? Or we just close this and I'll stick to my monkeypatch:

// Patch nextTick with a version that doesn't use setTimeout() so that our
// messages don't suffer artificial lag
shareDbUtils.nextTick = async function(callback: Function, ...args: any[]): Promise<void> {
  await macrotask();
  callback(...args);
};

function macrotask(): Promise<void> {
  const channel = new MessageChannel();
  return new Promise((resolve) => {
    channel.port1.onmessage = () => {
      resolve();
      channel.port1.close();
    };
    channel.port2.postMessage('');
  });
}

Copy link
Collaborator Author

@alecgibson alecgibson Mar 28, 2024

Choose a reason for hiding this comment

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

I also just realised that this PR won't actually help our situation 🤦🏼‍♂️ We have to include process anyway (I think other Node.js polyfills might rely on it, like util, which ShareDB also needs).

The only way this would help us is if we moved the MessageChannel approach to be the first approach (above process.nextTick()), but I can understand that might not be palatable?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Although I've dug a bit and it seems like the process thing is a bug, and we can avoid needing util completely. Have separately raised #648

Original file line number Diff line number Diff line change
Expand Up @@ -95,9 +95,20 @@ exports.nextTick = function(callback) {
args[i - 1] = arguments[i];
}

setTimeout(function() {
if (typeof MessageChannel === 'undefined') {
return setTimeout(triggerCallback);
}

var channel = new MessageChannel();
channel.port1.onmessage = function() {
triggerCallback();
channel.port1.close();
};
channel.port2.postMessage('');

function triggerCallback() {
callback.apply(null, args);
});
}
};

exports.clone = function(obj) {
Expand Down
33 changes: 33 additions & 0 deletions test/util-test.js
Original file line number Diff line number Diff line change
Expand Up @@ -45,6 +45,39 @@ describe('util', function() {
});
expect(called).to.be.false;
});

describe('without MessageChannel', function() {
var _MessageChannel;

before(function() {
_MessageChannel = global.MessageChannel;
delete global.MessageChannel;
});

after(function() {
global.MessageChannel = _MessageChannel;
});

it('uses a different ponyfill', function(done) {
expect(process.nextTick).to.be.undefined;

util.nextTick(function(arg1, arg2, arg3) {
expect(arg1).to.equal('foo');
expect(arg2).to.equal(123);
expect(arg3).to.be.undefined;
done();
}, 'foo', 123);
});

it('calls asynchronously', function(done) {
var called = false;
util.nextTick(function() {
called = true;
done();
});
expect(called).to.be.false;
});
});
});
});
});
Loading