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

fix: use int instead of double for timeout type. #1469

Merged
merged 3 commits into from
Jan 26, 2019
Merged

fix: use int instead of double for timeout type. #1469

merged 3 commits into from
Jan 26, 2019

Conversation

bokuweb
Copy link
Contributor

@bokuweb bokuweb commented Jan 6, 2019

Hi :) I found FIXME comment in ops.rs. I think it is better to use int instead of double for timeout type in flatbuffer. Because delay is rounded by typescript side like following. If not, please reject this PR.

https://github.com/denoland/deno/blob/master/js/timers.ts#L180-L184

@ry ry requested a review from piscisaureus January 6, 2019 18:09
@piscisaureus
Copy link
Member

For a relative time-out value int is probably sufficient (it means the max time-out value is about 24 days). Are you sure it's definitely not an absolute value (ms since epoch) that's being passed?

@bokuweb
Copy link
Contributor Author

bokuweb commented Jan 7, 2019

@piscisaureus Thanks for your review. Sure. I confirmed that it was not passed.
For example when following code executed, timeout values are 3000, 2998.

setTimeout(() => console.log(1), 3000);
setTimeout(() => console.log(1), 6000);

@hayd
Copy link
Contributor

hayd commented Jan 7, 2019

When I tried before (I was the one who wrote the comment) I struggled to get js number to fbs int64 datatype working... The API was a little inconvenient, but is there.

IMO If we go with int32 then we should add a < maxint assert in ts (if we use int64 this wouldn't be needed iirc).

@bokuweb Did you try using int64 here?

@bokuweb
Copy link
Contributor Author

bokuweb commented Jan 7, 2019

@hayd OK :) Thanks for your comment. I did not try it. I think it is better.I'll fix it 👍

Ah... I see. Sorry, I did not understand... I tried it, but js number is not able to assign to long.
We have some options?

  1. keep using float.
  2. use int32 with assertion.
  3. other??

However assertion is a bit exaggerated ?
In chrome, setTimeout(() => console.log(1), 2147483647 + 1) is executed immediately.
It is rounded??
Should we emulate that behavior??

@bokuweb
Copy link
Contributor Author

bokuweb commented Jan 7, 2019

In Node.js if timeout value is larger than int32, emit warning and fire callback in next tick.

https://github.com/nodejs/node/blob/master/lib/internal/timers.js#L57-L66

Should we imitate it?

@hayd
Copy link
Contributor

hayd commented Jan 7, 2019

Yes. Good investigating!

@bokuweb
Copy link
Contributor Author

bokuweb commented Jan 7, 2019

@piscisaureus @hayd Thanks for your comments. I fixed.

js/timers.ts Outdated
if (delay > TIMEOUT_MAX) {
console.warn(
`${delay} does not fit into a 32-bit signed integer.
Timeout duration was set to 1.`
Copy link
Member

Choose a reason for hiding this comment

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

Please make it so there's not a line break in the template literal.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@ry Thanks 👍fixed.

@bokuweb
Copy link
Contributor Author

bokuweb commented Jan 24, 2019

@ry @piscisaureus Is there anything I can do in this PR? :)

@piscisaureus piscisaureus merged commit aaaa355 into denoland:master Jan 26, 2019
@piscisaureus
Copy link
Member

@bokuweb Looked good to me so I landed it. Thanks!

@bokuweb
Copy link
Contributor Author

bokuweb commented Jan 27, 2019

@piscisaureus Thanks for your review :)

@bokuweb bokuweb deleted the fix-timeout-delay-buffer branch January 31, 2019 08:41
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants