6 ms·

You’re coming from position of knowledge. I don’t memorize documentation because it changes often and I use 3-5 various languages over the month. For fun and pr

• simoncion 2y ago
  > ...there was no warning that between two lines of shutdown and delete BEAM could restart a child... If you're talking about calling 'terminate_child/2' followed by 'delete_child/2', there is a very explicit warning. From <https://hexdocs.pm/elixir/1.18.3/Supervisor.html#terminate_child/2 https://hexdocs.pm/elixir/1.18.3/Supervisor.html#terminate_c...> > A non-temporary child process may later be restarted by the supervisor. and from <https://www.erlang.org/doc/apps/stdlib/supervisor.html#terminate_child/2 https://www.erlang.org/doc/apps/stdlib/supervisor.html#termi...> > The process, if any, is terminated and, unless it is a temporary child, the child specification is kept by the supervisor. The child process can later be restarted by the supervisor. In the English-language docs, the warning is very clear: children that a supervisor will restart on termination may be restarted before you get around to calling 'delete_child'. Children with a restart type of 'permanent' will always cause a race between 't_c' and 'd_c'. Children with a restart type of 'transient' will cause a race if they terminate abnormally... which is a term defined by the same document that the warning comes from. You keep insisting that this stuff isn't documented. Are you perhaps reading a poor translation of the docs? > You’re coming from position of knowledge. No, I'm not. I've forgotten most of the details I ever knew about how the system works and only remember broad strokes. My experience with Erlang/OTP was scattered throughout my spare time over an eight to twelve month period ten years ago. Unlike you, I've never been paid to work with it, and you've worked with it far more recently than I. The reason I was able to direct you to the right part of the docs was because I said to myself "Wow, it would be fuckin stupid if you couldn't dynamically add children to a supervisor. I remember the Erlang docs being really, really good, so let's see if they failed to describe if and/or how this works.", and then spent like five minutes reading the docs and another couple cross-checking with the Elixir docs. > I don’t memorize documentation because it changes often... Do the rules for "+", "-", and (if present) "%" change often in most major languages when they are used with built-in types? [0] It's always well worth your time to learn the rules for commonly-used, bedrock parts of a language, major libraries, and runtime systems that you intend to use. Bedrock parts don't substantially change, because if they did, they would invalidate every program ever written against those parts. OTP provides a collection of bedrock parts, and supervisors are one such part. Memorizing docs is really stupid, but having a solid understanding of how the major things you use work is always worth the time. Seriously, how would you function as a programmer if you didn't know how addition or string concatenation worked? If you're using OTP's supervisors, having a good understanding of how they function is just as fundamental. > One random recent day on Go I spent 95% time in E+C and 5% in documentation. Sure, that makes some sense. OTP is far more complex and robust than anything Go offers, so it's quite a bit quicker to come up to speed with what's documented in the Go official docs than what's in the OTP docs. Also, as someone who has written Go professionally for the last five, ten years, I warn you that you're going to get turbofucked by the things that -if they are documented at all- are documented only in blog posts or random tutorials. Go is an absolute grab bag of poorly-documented sharp edges and surprising behavior. > I rely on „map mode” (how I can find knowledge) and not on „collect mode” (i.e. I keep knowledge)... [and] I can show anecdotal data of the impact. The impact of you failing to familiarize yourself with the necessarily-complex tools you chose [1] to use seems pretty clear to me. You got tripped up by documented behaviour that you didn't bother to understand, which caused you to spend hours looking for solutions that would have been clear after a ten minute trip to the documentation for the 'supervisor' module. Given what you've said elsewhere in this subthread about how your project is an "an enormous Jenga tower that's risky to breath around", I suspect that a significant number of your coworkers also refused to familiarize themselves with the tools they use. [0] No, they do not. [1] (or were obligated)
  • xlii 2y ago
    > Children with a restart type of 'permanent' will always cause a race between 't_c' and 'd_c'. Children with a restart type of 'transient' will cause a race if they terminate abnormally... which is a term defined by the same document that the warning comes from. This is not written anywhere explicitly in the docs - I also agree that Erlangs documentation is much better but I’m not saying that Erlang is missing information. I’m talking about Elixir not providing this and marking clearly - because if I need to start reading in Erlang first then why would I layer Elixir on top of it? This is exactly the thing I’m pointing out. Because your response is long Ill only focus on this point and (hopefully) get back later. My expectation (implicit) would be that when function is doing 2 lines the messages would be locally ordered. Yes, maybe that’s silly, but in many other languages that’s exactly the case. If I send messages to queue I’m aware that queue might not get two of those. I need to send a transaction, fine. If I broadcast or make a signal/event same happens. But here I have synchronous function with no indication or warnings that it’s a message. If this can’t be known in documentation, isn’t caught by compiler/analysis, but requires experience or (often) reading source code it is implicit knowledge. Yes, I posses it too now, but I think it’s a problem.
    • simoncion 2y ago
      > This is not written anywhere explicitly in the docs. It absolutely is. I'll use the Elixir docs as my source: > A non-temporary child process may later be restarted by the supervisor. And, further up in the docs when talking about the circumstances under which a supervisor will restart a child that has terminated: [0] Restart values (:restart) The :restart option controls what the supervisor should consider to be a successful termination or not. If the termination is successful, the supervisor won't restart the child. If the child process crashed, the supervisor will start a new one. The following restart values are supported in the :restart option: :permanent - the child process is always restarted. :temporary - the child process is never restarted, regardless of the supervision strategy: any termination (even abnormal) is considered successful. :transient - the child process is restarted only if it terminates abnormally, i.e., with an exit reason other than :normal, :shutdown, or {:shutdown, term}. For a more complete understanding of the exit reasons and their impact, see the "Exit reasons and restarts" section. And the "Exit reasons and restarts" section says: [1] > A supervisor restarts a child process depending on its :restart configuration. For example, when :restart is set to :transient, the supervisor does not restart the child in case it exits with reason :normal, :shutdown or {:shutdown, term}. You go on to say: > But here I have synchronous function [to affect the state of a supervisor] with no indication or warnings that it’s a message. Before I get into that, I have two questions for you: 1) How do you affect an Erlang or Elixir process without sending it a message? The docs for Processes [2] don't indicate any other way. 2) Have you never seen or written a function that does not return until it receives the response to an async operation? Continuing on... from the top of the Supervisor docs, we see: > A supervisor is a process which supervises other processes, which we refer to as child processes. "A supervisor is a process...", straight off the bat. That's super clear and explicit, but I'll keep walking through the docs to show you how else this information is communicated to the reader. If we read on, we see that the first argument to the 'stop_child/2' and 'delete_child/2' functions is of type 'supervisor()', which is defined as '@type supervisor() :: pid() | name() | {atom(), node()}'. What are these? Well, check the docs for how you start a Supervisor. [3] They say three interesting things: 1) The second argument to 'start_link/2' is of type 'option()', which is defined as '{:name, name()}', and 'name()' is defined as 'atom() | {:global, term()} | {:via, module(), term()}' . Keep those types in mind. 2) "If the supervisor and all child processes are successfully spawned (if the start function of each child process returns {:ok, child}, {:ok, child, info}, or :ignore), this function returns {:ok, pid}, where pid is the PID of the supervisor. If the supervisor is given a name and a process with the specified name already exists, the function returns {:error, {:already_started, pid}}, where pid is the PID of that process." Notice how often it talks about "spawning" the supervisor and returning a PID, and saying that that PID is the PID of the supervisor you just created, or of a named supervisor that already exists. 3) "The options can also be used to register a supervisor name. The supported values are described under the "Name registration" section in the GenServer module docs." Let's look at the "Name registration" section. [4] I'm not going to quote the whole thing because it'd be a nightmare to reformat sensibly, but the two key sections are > Both start_link/3 and start/3 support the GenServer to register a name on start via the :name option. Registered names are also automatically cleaned up on termination. The supported values are: an atom ... {:global, term} ... {:via, module, term}... and the last four items in the bulleted list in the section beginning with > Once the server is started, the remaining functions in this module (call/3, cast/2, and friends) will also accept an atom, or any {:global, ...} or {:via, ...} tuples. In general, the following formats are supported: Notice how those bullets match up to the 'name()' type that is passed in to supervisor:start_link/2, and connect that information with the fact that the docs for that function direct you here to learn about how you can register a name for your supervisor. Combine that information with the fact that the first argument to the "Tell the supervisor to do something" functions is of type 'supervisor()' and the fact that 'start_link' returns a PID, and it's really, really clear that a supervisor is another process that you can (optionally) name and refer to by name, rather than PID. Once we understand that a supervisor is a process, and that the functions to instruct a supervisor to do things require the information required to contact a process, what other conclusion can we draw than "Communications with a supervisor is async, because communications with all processes are async."? [0] <https://hexdocs.pm/elixir/1.18.3/Supervisor.html#module-restart-values-restart https://hexdocs.pm/elixir/1.18.3/Supervisor.html#module-rest...> [1] <https://hexdocs.pm/elixir/1.18.3/Supervisor.html#module-exit-reasons-and-restarts https://hexdocs.pm/elixir/1.18.3/Supervisor.html#module-exit...> [2] <https://hexdocs.pm/elixir/1.18.3/processes.html https://hexdocs.pm/elixir/1.18.3/processes.html> [3] <https://hexdocs.pm/elixir/1.18.3/Supervisor.html#start_link/2 https://hexdocs.pm/elixir/1.18.3/Supervisor.html#start_link/...> [4] <https://hexdocs.pm/elixir/1.18.3/GenServer.html#module-name-registration https://hexdocs.pm/elixir/1.18.3/GenServer.html#module-name-...>