Task.start vs TaskSupervisor

[peerreynders]

@fxn

Could you folks help me understand what could happen in the Task.await/1 call in the original code?

elixir-lang/elixir/blob/v1.9.4/lib/elixir/lib/task.ex#L602-L603

Kernel.exit/1

See also:

Can you rescue/catch process exits in a Task?

It’s a bit more complicated than that: defmodule Demo do def run(arg) do try do result = do_it(arg) IO.puts("Value from local return #{inspect result}") rescue e in ArgumentError -> IO.puts("An Argument error occured #{inspect e}") # Look at Kernel.defexception/1 and the Exception behaviour catch :exit, {:error, msg} -> IO.puts("Exit from a called function: #{msg}") # BUT a callee inside the same process can decide to …

Kernel.raise/1 is an Elixir style exception - exit/1 is the original Erlang style process exception which can be caught within the process but will terminate that process if it is not caught.

---

Therefore, it receives exit signals from the task as messages.

Signals relate to process links (and convert to :EXIT messages when trapped) - :DOWN messages relate to monitors - two entirely separate mechanisms.

---

it is not clear to me if Task.await/1 is correct in a Phoenix Channel at all because it enters a receive block to consume messages directly from the process mailbox. What do you think?

That is the fundamental issue with await - it blocks the process outside of the OTP code. But keep in mind that even calls with GenServer.call/3 to another process are blocking. So there are situations where it can be OK - it’s more of an issue of awareness of blocking behaviour.

---

On the other hand, Task.await/1 emits exit signals from within that receive block

Your channel/topic process is executing await/2 and therefore exit/1 - so it’s not a signal yet - it can still be stopped with a try..catch.

---

How is the supervisor of the WS going to react to those signals?

If uncaught the channel/topic process will be terminated. I’m not sure how the supervisor is configured, so I can’t predict its behaviour.

---

Further update:

phoenixframework/phoenix/blob/main/lib/phoenix/channel.ex#L407-L414

So by default the channel/topic process won’t be restarted (from the server end) - “any termination (even abnormal) is considered successful”.

phoenixframework/phoenix/blob/main/lib/phoenix/socket/pool_supervisor.ex#L42-L58

And if I’m reading this right the supervisor is running with default max_restarts: (3) and :max_seconds (5) i.e. if there are more than 3 restarts within 5 seconds the supervisor will terminate.

So it looks like intensely crashing channel/topic processes will in fact terminate the pool supervisor easily.