Remove upper bound of 1 for quotas #514
Conversation
| @@ -289,7 +289,7 @@ check_quota_arg(VALUE quota) | |||
| if (TYPE(quota) != T_FIXNUM && TYPE(quota) != T_FLOAT) { | |||
| rb_raise(rb_eTypeError, "expected decimal type for quota"); | |||
| } | |||
| if (NUM2DBL(quota) <= 0 || NUM2DBL(quota) > 1) { | |||
| if (NUM2DBL(quota) <= 0) { | |||
There was a problem hiding this comment.
a quota ratio > 1 should have the same effect as a quota of 1.
This would mean that there as many (or more) available tickets as there are protected resources.
I don't see any benefit to removing this restriction, can you elaborate on your reasoning for removing it?
There was a problem hiding this comment.
In the case where I expect a worker to access the same resource multiple times concurrently, I think we need a quota > 1.
There was a problem hiding this comment.
Is that the case in Puma or something, where we have a single linux process with multiple ruby threads? I thought that they were backed by pthreads though (which linux should see as separate processes in the context of sysv api, i think?), so wouldn't it be better to have each worker register accordingly?
Unless it is somehow impossible based on the threading model, I think having each worker register (and thus, inherently raise the number of available tickets) is preferable to changing the quota logic.
Offhand, I can only think this could possible be the case for ruby fibers, but even then, only one can actually be active at a given time so they should be able to release the resource when they are done with it.
Can you elaborate more on in what context a worker would need to access the same resource concurrently? And in this context, what is a "worker" as it relates to the ruby and linux threading models?
No description provided.