odohMei7
Is `Process.send_after(pid, msg, time, opts \\ [])` garbage collected when pid shuts down?
I am using Process.send_after(self(),:wakeup, 100_000) to trigger a GenServer handle_info callback and I am wondering what happens when I have many such GenServer processes come and go. Will the scheduled send_after eat up memory before they are triggered and send to a nonexisting process? Or are they garbage-collected when the process with destination process ID shuts down?
I use process id (not named processes) in the send_after command.
My question is basically if I can be lazy and forget scheduled send_after on GenServer shutdown or if I should honor the returned timer reference and do cancel_timer on GenServer shutdown.
Marked As Solved
garazdawi
In general all resources of a process are expected to be cleaned up when the process terminates and timers are no exception. So it is safe to be lazy.
Also Liked
dimitarvp
I would always capture the return value of Process.send_after and use cancel_timer on it after a certain deadline but that’s mostly a matter of principle. Erlang’s VM is doing just fine in such scenarios and won’t buckle unless you bombard it with a few million of those (and even then it’s questionable if it’s going to buckle).
Also :erts_debug.size(timer) gives us 3 machine words so no need to worry about memory overhead either.
garazdawi
yes it is
Popular in Questions
Other popular topics
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #websockets
- #supervisor
- #advent-of-code
- #elixirconf-us
- #distillery
- #processes
- #forms
- #api
- #metaprogramming
- #security
- #performance









