Erlang/OTP 27.0-rc1 Released

Erlang News & Announcements Erlang News
21

For further detail, observer is used by trace_runner, and trace_runner only cares about ttb.
It seems like tremendous overkill to have to include wx in order to use ttb.

Perhaps ttb could be moved to, say, runtime_tools instead?

2 Likes
22

Optional applications Seem not to be totally ready.

Let us agree that when you ship an application, it is not the final user that looks through the release and removes “wx”, because the user doesn’t want “wx”. Instead it should be the one building the release that decides whether or not to include “wx” in that specific release.

This means that one must add some directives to rebar3 release building to specify this choice of inclusion or exclusion of the optional application.
Something like {include_optional_applications, []} (where I assume that one always wants to build a minimal release, otherwise exclude_optional_applications may be the better term.

Release handler then needs to figure out whether “wx” is optional for ALL other applications, otherwise should be included anyway. So work needs to be done, contrary to what is said in this post: support for optional_applications · Issue #2473 · erlang/rebar3 · GitHub

1 Like
23

I think it could be useful to be able to specify three different types of ‘release’ specification:

  • fully qualified: only consider the apps actually mentioned, and if a mandatory dep is missing, fail
  • semi-qualified: automatically wink in required dependencies, but no optional ones, unless they are listed in the spec
  • auto: the way it works today

The way the code is structured, rebar_relx.erl seems like the best place to do this.

BTW, isn’t this an error?
https://github.com/erlware/relx/blob/main/src/rlx_app_info.erl#L123-L124

BR,
Ulf W

24

It may be a bug on relx? An optional application must not be started (and perhaps not included in the release) unless someone else depends on it as a non-optional application. Optional applications are to enforce order, but not a requirement.

25

The new function proc_lib:set_label/1 can be used to add a descriptive term to any process that does not have a registered name. The name will be shown by tools such as c:i/0 and observer, and it will be included in crash reports produced by processes using gen_server, gen_statem, gen_event, and gen_fsm.

This is the feature I’m most excited about! I think it has the potential to make inspecting our systems much easier, especially once it’s widely adopted by libraries. But so far my tinkering hasn’t been fruitful. I made a gen_server which crashes on purpose, and I don’t see the label in the stacktrace that prints in the logs.

[error] GenServer #PID<0.628.0> terminating
** (RuntimeError) boom
    (myapp 0.1.0) lib/myapp/boom.ex:20: Boom.handle_info/2
    (stdlib 6.0) gen_server.erl:2158: :gen_server.try_handle_info/3
    (stdlib 6.0) gen_server.erl:2246: :gen_server.handle_msg/6
    (stdlib 6.0) proc_lib.erl:323: :proc_lib.init_p_do_apply/3
Last message: :time_to_die

I also don’t see it in :observer_cli.

|No | Pid        | MsgQueue  |Name or Initial Call                 |      Memory | Reductions          |Current Function                  |
|20 |<0.628.0>   |0          |Elixir.Boom:init/1                   |   10.4922 KB| 407                 |gen_server:loop/7                 |

I do see it in Process.info(:dictionary).

iex> pid("0.628.0") |> Process.info(:dictionary)
{:dictionary,
 [
   "$initial_call": {Boom, :init, 1},
   "$ancestors": [MyApp.Supervisor, #PID<0.390.0>],
   "$process_label": "boomer"
 ]}

I dream of a day when most processes have some kind of label, and a message like 12:16:43.041 [error] Postgrex.Protocol (#PID<0.580.0>) disconnected: ** (DBConnection.ConnectionError) client #PID<0.109924.0> exited can tell me more about what client is.

2 Likes
26

It seems you use elixir, and this is erlangs release notes :slight_smile:
The crash log is not how it looks in erlang so something logs it differently in elixir.

Also observer_cli is not something we (OTP team) is making, so that is up to the observer_cli developers, to support.

observer gui and etop shows it and the process list in the erlang shell.

2 Likes
27

Yes I did realize that much. :laughing:

Whoops, I assumed that Elixir used underlying Erlang code for this.

Initially :observer was not available, but looks like I needed to add it to extra_applications:; I see now that it does show the label. :+1:

1 Like
28

Would this be sound advice around using proc_lib:set_label/1? “The only downside to using it everywhere is extra memory usage; as elsewhere, using atoms instead of strings/binaries is more efficient.”

Any other operational advice?

BTW thanks so much for implementing this @dgud :heart:

29

I am not sure I would phrase it as such. For example, if the string/binary is a literal in the source code, I believe it is part of the literal pool and therefore there is no additional allocation.

Or even in dynamic cases. Imagine you are building an application to check if a host name is up. To do so, you spawn one process per host. For visibility, you want to set the label of each process as the host name. It will be a string/binary and not an atom, but the host name is likely already part of the process data/state (alongside other things which are most likely more expensive). I believe ssl itself uses the label based on the host and the port.

For example, in my Phoenix applications, I would set the label in LiveViews to something like {:user, socket.assigns.current_user.id}. This means that, once I see failures in logs, I can correlate them to actual users of my application.

2 Likes