md`## Insights 이 노트북을 작성하며 얻게된 생각들을 정리해봤습니다. **visualixir 는 프로세스간의 연결 관계를 구성할 때, \`Process.info\` 의 결과 중 \`:links\` 값만 사용합니다.** ~~~elixir iex> pid(0,84,0) |> Process.info(:links) {:links, [#PID<0.85.0>, #PID<0.43.0>]} ~~~ 링크는 Elixir 이 프로세스에서 발생한 에러를 다루는데 사용하는 동작입니다. 링크된 두 프로세스 중 한쪽 프로세스가 종료되면, 나머지 프로세스에 종료 메시지가 전달됩니다. 두 프로세스를 링크하기 위해서는 \`.start_link/3\` 혹은 \`Process.link/1\` 함수를 사용합니다. 프로세스의 링크 정보는 \`Process.info(pid, :links)\` 함수로 조회할 수 있습니다. 프로세스의 링크 정보를 force simulation 으로 배치하면 마치 계층적인 정보인것 처럼 보이지만, 그렇지 않습니다. 링크 함수를 호출하는데는 별다른 제약이 없으며, 양방향이라 한쪽에서 링크 함수를 실행하면 링크된 프로세스에도 정보가 기록됩니다. 계층 구조의 데이터라면 부모 - 자식으로 구분이 가능해야 합니다. 하지만 프로세스 링크 정보를 부모 - 자식 관계로 나누어가다보면 부모가 둘 이상이거나, 없는 프로세스들 때문에 변환이 불가능합니다. 계층 구조 데이터로 변환할 수 있다면 공간을 좀 더 효율적으로 사용할 수 있는 계층 구조 레이아웃을 사용해 표현할 수 있는데 이것이 불가능한 셈입니다. **observer 앱은 어떻게 프로세스들을 계층 구조로 표현하나?** Erlang [runtime_tools](http://erlang.org/doc/man/runtime_tools_app.html) 에 포함된 observer 앱에서는 어플리케이션 별로 프로세스의 구조를 계층 구조 레이아웃 중 하나인 dendrogram 과 유사하게 보여줍니다. 프로세스들의 연결관계를 부모 - 자식 관계로 나눌 수 있는 기준이 존재한다는 것을 깨달은 저는 [Erlang 의 저장소](https://github.com/erlang/otp)를 뒤져 [appmon_info](https://github.com/erlang/otp/blob/a18ec86bb6f860456af992d78abf0dae51bb713a/lib/runtime_tools/src/appmon_info.erl) 프로세스의 코드를 찾아내었습니다. \`appmon_info\` 프로세스는 node 에서 시작된 프로세스들을 어플리케이션 별로 나누어 tree 형태로 저장합니다. observer 앱은 \`appmon_info\` 프로세스를 통해 어플리케이션 별로 프로세스들의 관계를 조회하고, 표현합니다. Iteration 6 의 결과로 볼때, appmon_info 는 링크 정보를 사용하지 않으며, 어플리케이션에 포함된 모든 프로세스들을 저장하지 않습니다. 하지만 \`appmon_info\` 의 데이터는 supervisor 프로세스를 기준으로 [supervision tree](http://erlang.org/doc/design_principles/des_princ.html#supervision-trees) 를 정확하게 표현합니다. \`appmon_info\` 프로세스는 runtime_tools 에 포함되어 있으며, observer 앱과 함께 실행되지만, 필요하면 직접 실행할 수 있습니다. ~~~elixir iex> :appmon_info.start_link(node(), self(), []) {:ok, #PID<0.113.0>} iex> Process.whereis(:appmon_info) |> :appmon_info.app(:kernel, true, []) :ok iex> flush() {:delivery, #PID<0.113.0>, :app, :kernel, {'<0.45.0>', [ {#PID<0.68.0>, 'logger_sup'}, {#PID<0.69.0>, 'logger_handler_watcher'}, #... ~~~ **visualixir 는 프로세스들의 관계를 제대로 표현하는가?** visualixir 를 분석하기 전에는 이런 궁금증은 없었습니다. 하지만 observer 와 visualixir 의 표현이 다르다는 것을 알게되고, \`appmon_info\` 프로세스의 코드를 분석하면서, visualixir 가 표현하는 방식이 Elixir 프로세스들의 관계를 제대로 표현하는 것인지 생각해보게 되었습니다. visualixir 는 앞서 살펴본 대로 프로세스들 간의 링크 정보를 활용합니다. 시스템에서 실행중인 프로세스들을 모두 조회해서 배치한 후 링크 정보를 표현하기 때문에 Node 에 실행중인 프로세스들을 빠짐없이 확인할 수 있습니다. 하지만 링크 정보는 계층 구조가 아니기 때문에 효율적인 배치는 불가능합니다. 또한 링크 정보는 Elixir node 를 이해하는데 반드시 필요한 정보는 아닙니다. 프로세스간의 message passing 과 supervisor - children 관계가 Elixir node 의 수많은 프로세스를 이해하는데 더 도움이 됩니다. visualixir 의 표현방식은 모든 프로세스가 화면에 배치되기 때문에 message passing 을 표현할 수 있습니다. *visualixir 의 message passing * \`appmon_info\` 는 실행중인 모든 프로세스를 확인할 수는 없습니다. superivor 프로세스를 중심으로 supervision tree 를 표현하기 때문입니다. 프로세스를 감시하고 종료되었을 때 다시 실행하는 superivor 프로세스와 자식 프로세스의 관계는 Fault Tolerance 의 기반이 되는 개념으로 매우 중요합니다. 이 관계를 표현하는 것은 시스템을 이해하고 다루는데 도움이 됩니다. supervision tree 는 계층구조이기 때문에 화면에 효율적으로 배치될 수 있습니다. 하지만 모든 프로세스가 supervision tree 에 포함되는 것은 아니기 때문에 message passing 을 표현하기 어렵습니다. | 데이터 | 표현 방식 | message passing ---|---|---|--- \`visualixir\` | 프로세스간 링크 정보 | force simulation | 표현 가능 \`appmon_info\` | supervision tree | hierarchy (force simulation 포함) | 표현 불가능
`

Purpose-built for displays of data