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

Parity with yab ratelimit #10

Closed
achals opened this issue Oct 4, 2017 · 6 comments
Closed

Parity with yab ratelimit #10

achals opened this issue Oct 4, 2017 · 6 comments

Comments

@achals
Copy link

achals commented Oct 4, 2017

I was trawling through the yab ratelimiting code, and noticed that the interface exposed there is different (and IMO nicer) than the interface in this package.

Is this package intended to be kept updated? If so, would it be possible to update the implementation to bring it up the parity? I'd be more than happy to contribute a PR if it would help. It would be great to be able to use rate limiting logic independently of yab.

@kriskowal
Copy link
Contributor

A change of this kind would require a major version bump. It could be done, since nothing we know of uses this package yet. Ideally we would use this package as a dependency in yab. I’d like to know what @prashantv thinks.

@kriskowal
Copy link
Contributor

To clarify, the difference is that yab’s take accepts a cancel channel.

@prashantv
Copy link
Contributor

Since we haven't cut any releases, I think it's fine to change the interface.

I think the ideal interface would take a context.Context for cancellation.

@achals
Copy link
Author

achals commented Oct 7, 2017

So I have a branch locally that updates the interface to accept a context.Context; it seems to be mostly working but ExampleRateLimit has way more variance than earlier:

--- FAIL: ExampleRatelimit (0.09s)
got:
1 10.935692ms
2 9.814699ms
3 11.718343ms
4 9.582154ms
5 8.356239ms
6 12.062452ms
7 8.729969ms
8 8.911591ms
9 9.937449ms
want:
1 10ms
2 10ms
3 10ms
4 10ms
5 10ms
6 10ms
7 10ms
8 10ms
9 10ms
FAIL

Again, go newb, but is switching to using select to block on channels supposed to add that kind of over head? I can make a PR if it helps the discussion.

@achals
Copy link
Author

achals commented Oct 10, 2017

Ignore my earlier comment, I was misusing the Clock interface, which I've actually removed in my PR.

@nathanhack
Copy link

Is there a status on when the PR for this might be merged?

@achals achals closed this as completed May 27, 2021
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

No branches or pull requests

4 participants