100phlecs
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.
Where Next?
Trending in Discussions
Other Trending Topics
Latest on Elixir Forum
Sponsor Spotlight
At WyeWorks, we believe great software is built by combining technical excellence with genuine human connection
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #library
- #deployment
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #ai
- #elixirconf-us
- #blog-post
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #hex
- #security
- #metaprogramming
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Error tracking, logs, uptime, and Just Enough APM. Built for developers.
Elixir, Erlang & BEAM conferences from Code Sync - join us in 2026!
Practical resources that improve the lives of professional developers.
Master modern tools, write cleaner code, and tackle real-world challenges.
Producing high quality Elixir screencasts since 2017.
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"
Showing Posts 1 to 3- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
lud
Tasks started with
Task.async/1are 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/2will give you better observability than a merespawn_link/1. Starting a single supervisor for all your tasks is not heavy at all. So I think your choice was good.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.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.