-
Notifications
You must be signed in to change notification settings - Fork 49
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
Implement waiting max concurrency #34
Comments
have this issue is still on to do status or it has been finished? |
It is still todo. The more I thought about it, the more worried I became that it would be dangerous. Do you have a strong need for this: curious about your use case. |
for me, it is not strong need for me, but i am curious on this issue. i want to contribute this with a PR, but maybe not that fast, this required me to finish in spare time |
For this feature, I worry the circuit code is already complex and it may be best if this was implemented as a wrapper on top of the circuit. It may look like something like this
The exact code will probably be a bit different and maybe require some good error checking, but the idea is to move this code outside of this already complex package into a wrapper. If you want to contribute something like this on your personal github, I would gladly accept a pull request to reference your implementation inside this repositories README file.. Let me know if you need more details. |
so what i should do in this implementation? iam still not that much understand the demand of this issue, what i am understanding accroding to u
is that should i implement a wrapper and handling the concurrency without affecting the code of exist circuit? |
so far i dive deep into this code, is just burtually return error when inside circuit.run() allowNewRun just return false |
Rather than modify any code inside this repository, create a new struct that uses a circuit as a member. |
I think there is no need to use semaphores for that. When we need max concurrency set it is better to fail fast and create back pressure, rather than have bunch of stalled requests. |
Add a feature that uses https://github.com/golang/sync/blob/master/semaphore/semaphore.go to limit concurrency. In this implementation, rather than failing fast with an error, the function would wait according to the context if was at a limit of MaxConcurrentRequests
The text was updated successfully, but these errors were encountered: