Using Task.start with receive -- is this the same as Task.async?

Hello! I am studying the Task module and I am trying to teach myself some patterns of concurrency in Elixir. I found something like this while reading the documentation for Process.sleep/1:

Task.start_link(fn ->
      send(parent, :work_is_done)

receive do
  :work_is_done -> IO.puts("Task complete!")
  2_000 -> IO.puts("Operation timed out.")

My question is: is this the same as using Task.async?

async_task = Task.async(fn ->

val = Task.await(async_task)
# :work_is_done

So this gives me 3 questions (related) that I hope someone can explain to me:

  1. Does Task.await function the same way as the send + receive example? (I like the syntax of Task.async and Task.await, but I want to make sure this is only syntax difference)
  2. I tried doing send/recieve from Task.start/1 and it seems to work the same as Task.start_link/1. Is there case where Task.start/1 must be used or case where Task.start_link/1 must be used?
  3. If I have a list of tasks, is it always better to use Task.async_stream? I tried using to put many Task.asyncs together and it seems like Task.async_stream is a better way.

Thank you! I want to try to understand this well before I study GenServers.

  1. Generally yes. There is more stuff that is done underneath but at the end we use send and receive. The same information you can find in the documentation:

One of the common uses of tasks is to convert sequential code into concurrent code with Task.async/1 while keeping its semantics. When invoked, a new process will be created, linked and monitored by the caller. Once the task action finishes, a message will be sent to the caller with the result.

  1. Yes, you use start_link instead of start when you want to start a process linked to the current process. You can find more information about linking here:

  2. Yes, Task.async_stream be first thing to consider. If it doesn’t meet your requirements, then you can combine Task.async with Enum/Stream functions.

Thank you for your response! I think this is beginning to make sense.

It’s not exactly the same. Task.async is a bit smarter than that, because when you call it it saves a reference. When the await catches the message, it pattern matches against the reference to make sure it’s matching against the right task.

This protects against the situation where tasks cross streams. In the Task implementation, you can do this:

|> ->

And your 1…10 will come back in order; they will not with your await implementation.

Check the elixir code for task.await:

This pattern will reappear in, so understanding it is probably a good idea :smiley:

1 Like

Also, if you’re still early on, Task is kind of still only the first layer on top of spawn. I use it a lot in tests, but I think for anything that hits prod you should consider Task.Supervised functions. It may not be necessary to fully understand yet depending on where you are in elixir learning.