Why are there no warnings when a process send a message to itself?

Questions / Help
, , ,
1

Note: this question is based on a misunderstanding. It seems like one cannot delete a topic in the forum, so it will remain forever as a testament to my lack of reasoning ability.

I got bitten hard yesterday by a mistake I made in a live component. The code looked something like this:

defmodule ScribeWeb.PageContentGenerator do
  use MyWeb, :live_component

  . . .

  def handle_event("an_event", _, socket) do
    pid = self()

    page_id = generate_page_content!(
      handler: %{
		on_llm_new_delta: fn _model, delta ->
          if delta.content do
			send(pid, {:delta, delta.content})
		  end
		end
      }
    )

    {:noreply, assign(socket, page_id: page_id)}
  end

  . . .
end

I’m not a very experienced Elixir developer, and I didn’t understand why it didn’t work. It took a long time to realize the view had frozen when I called send. Because that is what happens, right? The view froze until I added the call to generate_page_content! in a Task.async.

I can’t be the first one to make this mistake. It’s easy to do, and when you do, things behave strangely, which makes it hard to debug.

It got me thinking. I’m curious to hear: why am I allowed to send a message from a process to itself? And if there are good reasons for sending messages to oneself sometimes, couldn’t this be done via a send_to_myself function?

I’m sure the current design is the result of a lot of thinking and experimenting. I’m curious to hear why there are no guard rails, hindering or at least warning me, when I lock a process.

2

That shouldn’t be the root cause here. Send doesn’t block, no matter if you send a message to yourself or another process – alive or not.

There are also a lot of valid usecase to send a message to oneself.

1 Like
3

Oh, could the problem be that the view process can’t receive any message until the handle_event call has returned?

4

Then this question is based on a misunderstanding. Maybe I should remove it.

5

You can call receive just fine within that handle_event. No handle_info will run concurrently though – a given process can only sequentially run code.

6

This is my current understanding then.

The handle_event call is not returning, because generate_page_content! is running while calling callbacks. These callbacks are invoked and they are sending messages. The messages are received in the inbox but since the process is currently running the handle_event function they wont be handled until it returns.

7

That’s correct understanding. The only way to make this work is by not blocking till generate_page_content! returns to make the handle_event function return. Moving generate_page_content! to a separate process would do so, but you’d not be able to work with it’s return anymore within the handle_event.

1 Like
8

Ok, thanks