1. 15
  1.  

  2. 4

    takeaway from this should be; process_info/1 is not what you want. problem is it loops over (most of) the process_info/2 variants.

    1. 2

      OTP today already uses the process dictionary to publish information about processes:

      $ancestors and $initial_call are put there and proc_lib:initial_call/1 fetches the pdict for a given pid and reads the $initial_call key. That suffers from the same problem.

      I wish Erlang would allow selectively reading a key from another process' pdict. That would solve a whole class of problems about how to publish information about a process that should be cleaned up when it dies.

      1. 1

        Wouldn’t the proper thing to do in that case though either be to store that information in the process’s supervisor, or in mnesia or ets or something?

      2. 1

        Do the additional copies ever get GC’d?

        1. 1

          Yes.

        2. [Comment removed by author]

          1. 8

            Do you honestly think that’s the TL;DR of the article? Do you think every person using Erlang and calling into process_info/1,2 knows about this issue?

            1. 6

              I think it makes sense because nothing is shared. The info must be copied. What is unclear is the procedure by which it is done: does it use some sort of hidden signal/message kind of deal that needs to be scheduled, or does it just go ahead and read into the memory of other processes before copying it, for example.

              1. 2

                A quick glance at the code tells me the later is the case.

                I agree this makes sense, since how Erlang is expected to work by “share nothing”. Still might be a surprise in production when trying to find out what processes are causing a slow down or whatever, and then suddenly the memory going up to the sky without apparent reason.

              2. 2

                Given the semantics of Erlang I do not see how it could work any other way.

                1. 4

                  By this logic every “surprising” behavior from Erlang that is not accepted as a bug, could be reduced to “Given the semantics of Erlang I do not see how it could work any other way.” Not sure how’s that helpful.

                  1. 2

                    I guess I do not understand why this would be considered surprising behaviour at all.

                    1. 2

                      All I read is “I do not have empathy for other people”

                      1. 2

                        Fair enough. I think it is fair to assume people understand the basic semantica of their language but to each their own.

                        1. 11

                          While is fair to say that the following is not clear from the blog post, not everyone using an Erlang program knows how to program in Erlang, let alone the semantic details of it. There’s a fair amount of people running systems like RabbitMQ/Riak/Ejabberd in production that have no idea about Erlang, but they still need to debug it when things go wrong. Those people might be issuing commands to for example, get information about processes. Said people are expecting a printout of whatever Erlang thinks should go into process_info. I bet that if their system suddenly crashes since it ran out of memory due to calling said debugging facilities, the person will be surprised.

                  2. [Comment removed by author]

                    1. 3

                      You still have to copy the data to move it between processes.