Support for OTP 27 process labels

[hugobarauna]

Before example

After example

URL with a notebook showing the feature being used in multiple contexts: https://gist.github.com/hugobarauna/6dd8b05b51d66bf313c3870c2bc428ed.

You can import that notebook, with Livebook running with Elixir 1.17 rc and see the diagrams with process labels.

[josevalim]

Why do we need a process?

[hugobarauna]

This was my second approach, the first didn't work.

In the first one, I was trying to get the process label from the process registry directly, using :proc_lib.get_label/1. But the problem was that by the time I was calling that function, the process I was trying to access the label from could have already died.

That happened in that simple example:

parent = self()

Kino.Process.render_seq_trace(fn ->
  child =
    spawn(fn ->
      Process.set_label(:ponger)

      receive do
        :ping ->
          send(parent, :pong)
      end
    end)

  send(child, :ping)

  receive do
    :pong -> :ponged!
  end
end)

[josevalim]

Yes, that's expected, you will always have this race condition. It also happens for names. We only take a snapshot. We should avoid the tracer in my opinion.

[hugobarauna]

In the "ping <-> pong" example, it's not a race condition; it's deterministic

In this example, we won't be able to access the :ponger label using :proc_lib.get_label/1 because we first run the tracer function (the anonymous function passed to Kino.Process.render_seq_trace), and only after that do we'd try to access the labels of the processes inside. By that time, the :ponger process is already dead (deterministically).

Since the "ping <-> pong" example is our (theoretically) "canonical example" for showing the sequence diagrams for rendering message passing, I'd prefer if our solution would work for showing process labels for that example.

What do you think?

Maybe I'm not seeing the downside of using the tracer here, since it's the first time I'm using it.

One downside I can see in the current implementation is that if the developer sets the process label using :proc_lib.set_label/1 (from Erlang) instead of using the Elixir wrapper (Process.set_label/1), then the current code wouldn't get the process label. But we could easily address that by tracing that function call as well, if we want to."

[jonatanklosko]

Btw. we already have a tracker process, we could at least reuse it?

[hugobarauna]

Btw. we already have a tracker process, we could at least reuse it?

That may be possible. I can investigate that path.

[hugobarauna]

@josevalim ok, it should be fixed now.

Still there's a race condition, but I think it's ok.

For example, with the new solution, I was able to reproduce the race condition with that example:

parent = self()

child =
  spawn(fn ->
    Process.set_label(:ponger)

    receive do
      :ping ->
       # theres's a race condition here, without that sleep
       # when the tracer tries to get the process label
       # the ponger process is already dead
       Process.sleep(1) 
       send(parent, :pong)
    end
  end)

Kino.Process.render_seq_trace(fn ->
  send(child, :ping)

  receive do
    :pong -> :ponged!
  end
end)

Also, the old solution had a bug, as you mentioned, it could not get process labels set outside the traced function. Now that's working:

[hugobarauna]

@josevalim @jonatanklosko, I think this should be good to go. Can you please take a last look?

[josevalim]

One comment and we can ship it!!!!

[wojtekmach]

nitpick, I'd change to:

    label = process_label |> inspect() |> String.replace(~s{"}, "")
    "#{label}<br/>#{:erlang.pid_to_list(pid)}"

I tried pushing to main but I don't have access. :D No big deal anyway of course!