The default timeout for GenServer.call is 5 secs. While the caller is waiting, it is blocked. If you want the caller to be responsive to requests by other processes, then issuing the call to rate limiter from a separate process (e.g. a Task) might help. Another option is to expose the status in some public or protected ETS table. This could then be read without querying the process. The property feature of gproc essentially does this.
sasajuric
Author of Elixir In Action
2
fishcakez
Ecto Core Team
GitHub - jlouis/safetyvalve: A safety valve for your erlang node · GitHub provides exactly these features.
However sbroker master also provides a framework for building custom job regulators, there is even a property testing framework for the testing it. Its Erlang code but the simplest one limits the number of concurrent tasks: sbroker/src/sregulator_open_valve.erl at master · fishcakez/sbroker · GitHub. The regulator process plugs together a valve, a queue and a meter, and has 3 different ways to request to run, blocking with queue, blocking without queueing and asynchronous with queue. The queues and meters come with sbroker but you would need to write the valve. I would really like a PR adding this feature and can help with the property based testing.
5
swennemans
By the way, would making use of GenStage make any sense? I’ve watched the Genstage presentation, and it seems that I has some overlap (but haven’t played with it yet, so I could totally missing the point 
).
1
Qqwy
TypeCheck Core Team
@swennemans In the end, as projects in companies tend to go, the project moved a lot slower because of other work that was deemed more important at the time. So above idea still is mostly theoretical; I have not implemented it yet.
GenStage seems like a perfect fit for this problem. I have not used it a lot myself yet, so I cannot be 100% sure, but it looks like it simplifies constructing these kinds of concurrent pipelines a lot.
2