Maybe it could be moved to the client side of the API, but otherwise it would be a lot of boilerplate.
A point was raised on the Discord that this function could be a trap for people still getting used to idiomatic Elixir, and they proposed multiple other solutions, both in changing approach and how to do this without a Task or new GenServer function. I'll withdraw my proposal, and I'll summarize the discussion in the near future. On Thursday, September 2, 2021 at 2:30:09 PM UTC-7 José Valim wrote: > In this case, then I think I would have the GenServer return immediately > and say: you can call the service at time X. The client gets the response, > see how much time it is needing, and handles it accordingly. Either by > sleeping or by sending a message to itself. WDYT? > > On Thu, Sep 2, 2021 at 22:45 Khionu Sybiern <ksyb...@octoml.ai> wrote: > >> The idea is that the rate limiter process itself doesn't need to be held >> up because of the caller's need to respect the rate limit. Because the >> delay is immediately calculable at the time, that can be immediately >> delegated from the rate limiter process, allowing it to move on to the next >> request. >> >> On Thursday, September 2, 2021 at 12:28:31 PM UTC-7 José Valim wrote: >> >>> Hi Khionu, can you please explain a bit more about the design? Why does >>> it need to delay the response in such a way? Is it coming from the rate >>> limiter process itself? >>> >>> On Thu, Sep 2, 2021 at 21:02 Khionu Sybiern <ksyb...@octoml.ai> wrote: >>> >>>> I have a case where I use a GenServer to block other operations from >>>> happening in order to respect ratelimits of a third party. Right now, I >>>> spawn a Task that uses GenServer.reply after a sleep, then return >>>> :no_reply. Imo, it would be more ergonomic to have an equivalent to >>>> Process.send_after for GenServer.reply. >>>> >>>> Example: >>>> https://gist.github.com/khionu/7da26e1c53108ee4b462ef570f19b61b >>> >>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "elixir-lang-core" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to elixir-lang-co...@googlegroups.com. >>>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/elixir-lang-core/e4a0ef65-7075-4ffc-b5db-b5acd86365c7n%40googlegroups.com >>>> >>>> <https://groups.google.com/d/msgid/elixir-lang-core/e4a0ef65-7075-4ffc-b5db-b5acd86365c7n%40googlegroups.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>> -- >> You received this message because you are subscribed to the Google Groups >> "elixir-lang-core" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to elixir-lang-co...@googlegroups.com. >> > To view this discussion on the web visit >> https://groups.google.com/d/msgid/elixir-lang-core/db90f889-2e33-4d38-9069-7ed564cbba6dn%40googlegroups.com >> >> <https://groups.google.com/d/msgid/elixir-lang-core/db90f889-2e33-4d38-9069-7ed564cbba6dn%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- You received this message because you are subscribed to the Google Groups "elixir-lang-core" group. To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-core+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/4082a37d-a38b-4541-9926-ef36678d526cn%40googlegroups.com.