jberling
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.
Trending in Questions
Other Trending Topics
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #blog-post
- #elixir-ls
- #ai
- #elixirconf-us
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #hex
- #security
- #metaprogramming











Showing Posts 1 to 7- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
LostKobrakai
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.
jberling
Oh, could the problem be that the view process can’t receive any message until the handle_event call has returned?
jberling
Then this question is based on a misunderstanding. Maybe I should remove it.
LostKobrakai
You can call
receivejust fine within thathandle_event. Nohandle_infowill run concurrently though – a given process can only sequentially run code.jberling
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.
LostKobrakai
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. Movinggenerate_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.jberling
Ok, thanks