Consequences of choosing `Task.Supervisor` over `Task.async/1`?

Chat / Discussions
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.

1 Like
2

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.

3 Likes
3

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.

1 Like
4

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.

3 Likes