100phlecs
Consequences of choosing `Task.Supervisor` over `Task.async/1`?
Searching around online, it’s always recommended to have processes supervised.
So, instead of Task.async/1 one would use Task.Supervisor.start_child/3 which is what I chose to do.
But I’m wondering what use cases there are for Task.async/1 — the current advisory is to not to use any unsupervised processes as they may turn into non-terminating/zombie processes that would eventually cause problems.
But I guess it’s permissible if you know the Task you’re shooting off will end?
For Task.Supervisor you need to init by adding it your application children.
# application.ex
@impl true
def start(_type, _args) do
children = [
# ...
{Task.Supervisor, name: MyApp.TaskSupervisor}
]
# ...
Supervisor.start_link(children, opts)
end
Are there unforeseen costs/consequences to doing so, i.e. application load?
To bring this back to the real world, I have an async API call to make to an external service for a side effect and I do not need its response.
I don’t want this API call to block my main process/cause it to hang.
In terms of other modules I could use besides Task, this async API call isn’t within a hotpath of the app, so I don’t see the need for a heavier solution.
Most Liked
lud
Tasks started with Task.async/1 are fine in supervised processes as long as you await them or better, match the response message. Because the task will be linked to the calling process, any error will bubble up.
But in a fire and forget situation, Task.Supervisor.start_child/2 will give you better observability than a mere spawn_link/1. Starting a single supervisor for all your tasks is not heavy at all. So I think your choice was good.
gregvaughn
That’s one concern, but I don’t think it’s the main one. You can start off a process that runs an infinite loop and the beam handles it well. The larger concern is orderly shutdown behavior. In an orderly shutdown the supervision tree is walked and each supervisor tells its own children to gracefully terminate, within a configurable timeout. Unsupervised processes will never receive notification to shutdown gracefully, so they’ll be brutal killed when the beam shuts down.
dimitarvp
No, not really. BEAM has been tuned from the get go to have a ton of lightweight processes.
Seems you already know the differences between the two approaches you tried, and you got a good comment after that refining the explanation.
I’ll only add that if you are worried about tasks not terminating then you probably should use Oban.
Popular in Discussions
Other popular topics
Latest on Elixir Forum
Sponsor Spotlight
Enabling companies to succeed by building software people love.
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
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Real-time error tracking, performance insights, and observability for devs.
Practical resources that improve the lives of professional developers.
Develop your skills with books, videos, and courses.
The deployment platform built for Elixir: PaaS ease, VPS control.
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"