Erlang programming (Classic)

1. Message matching mode of the receive clause: if the message is simple and can be described using atom, tuple is unnecessary. tuple consumes more memory and slows down the processing speed of the process.
2. I () lists the details of the current process, and regs () lists the details of all registered processes and ports. ETS: I () lists the details of all ETS tables.
3. Atom will not be garbage collected, so registering for all processes may exhaust the memory. We recommend that you only register long-lived processes.
4. No error occurs when a message is sent to the PID, even if the process does not exist. However, when the registered process does not exist, an error occurs when a message is sent to the PID through the registration name.
5. The process does not process (MATCH) The received messages as a bug, because these unprocessed messages are constantly accumulated in the mailbox of the Process, causing memory leakage, system crash. Another problem with mailbox being too large is that every time a new message is received, all the old messages will go through, which slows down the processing speed of the process and shows a high CPU usage. In addition, large-capacity mailbox processes will also lag those processes that send messages to it (because Erlang runtime can be processed in a timely manner to enable large-capacity mailbox processes, it will take the initiative to slow down the processes that send messages to the process) But discarding these messages will make debugging difficult. Therefore, it is best to ensure that these unprocessable messages are recorded in the log.
   Such problems can be corrected through code optimization and careful debugging of OS and Erlang VM.
   In addition, the process of synchronous message sending is a way, the sending process sends a message and waits for a confirmation will slow down the growth of maibox messages. The side effect of synchronization is that it reduces the maximum throughput of the receiving and processing processes, but at least does not take the system down.
6. Erlang cannot completely avoid deadlocks. For example, process a synchronously calls process B (process a sends a message to process B and then waits for process B to return a Response Message), and process a (process B) synchronously calls process.
7. You can call process_flag (priority, priority) to adjust the priority of a process. However, you are not encouraged to adjust the priority of a process, or even disable it.
8. There are two types of inter-process connections: one is bidirectional, that is, link; the other is unidirectional, that is, monitor. The Connection established by the former is permanent, and the latter is temporary. The former can only establish contacts for existing processes, and the latter can monitor non-existing processes (of course, A {'down'..., noproc} message will be received immediately ). Obviously, the latter is suitable for Asymmetric processes, such as client-server.
9. It is best to call Erlang: demonitor (reference, [flush]) to release monitoring of processes, because the processes monitored before demonitor is called may be down.
10. If a process exits abnormally, an exit signal is sent to the link process set. The exit signal is transmitted like a domino card (each card is a process, and the process is terminated ). It can be understood that after process_flag (trap_exit, true) is called, the process converts the exit information of other processes received to {'exit ', PID, reason} messages, in this way, the dominoes are stopped from being dumped;
11. Normal Process Termination will not cause concern: when the process Exits normally, it will also send an exit signal to its direct link set, but this normal exit signal will not be further transmitted, that is to say, the normal exit signal will not cause the dominoes to collapse. (The process with the trap_exit flag set will convert the exit signal to the Message {'exit ', PID, normal }).
12. Two link processes on different computers, if the network connection between them is disconnected, will receive a message of {'exit ', PID, noconnection}
13. There should be no orphan process in a large Erlang system, that is, all processes must be connected to a huge supervision tree. There are two problems with orphan processes. First, they are not easy to find bugs: when these processes fail due to bugs, they are completely unknown. Another problem is "process leakage". When an orphan process crashes for some reason, it will keep hanging. As more and more processes are suspended, these accumulating orphan processes will eventually run out of memory.
14. The only task of a supervisor process is to subscribe the process and monitor it. Set the supervisor to trap_exit and link it to all sub-processes.
15. The online upgrade of Erlang is divided into two situations. The first case is that module A runs in the process and module A calls the function of Module B. The process running module A maintains a link to the latest version of Module B ), after Module B is reloaded, the link of Module B in the process will be switched to the latest version. In this way, module A will automatically call the updated function later. The second case is the upgrade of module A itself. The upgrade of the module running in the process is more complicated, depending on the method of calling the function in the module: direct call, or fully qualified function call (a call such as B: fun1 (). If it is called directly, the old version of the module is maintained after the module is reloaded, the fully qualified function call will immediately switch to the latest function version.
16. Only two versions of the module code are maintained during Erlang running. Therefore, after 2nd module upgrades, the oldest version of the module will be removed. If a process still runs the oldest version of the module, these processes will be terminated (killed) as the module of the oldest version is removed ).
17. There are three methods for Loading modules. The first is to directly call functions in the module. In this case, a process called code server (which is part of Erlang kernel) will search for the corresponding beam file and load it; the second method is to compile this module (the corresponding function is compile: file (module) and then the compiled module is automatically loaded. In shell, the compiled module is run through the command C (module ); the third chapter is an explicit loading module. By calling code: load_file (module) to reload the specified module, you can use the command l (module) to load the module on the local machine, in the network, you can run the NL (module) command to load the module to each node.
18. When running Erlang, the same module has two dimensions: the old one and the current one. When a new version is loaded in, the old one will be cleared, the current one will become old, and the new one will become the current one. The old and current modules have nothing to do with the actual version of the module, but are related to the loading time sequence (a module of the latest version may be loaded first, and then a module of the old version may be loaded later, in this case, the first loaded module is old, and the last loaded module is current ).
19. In Shell, press the tab key to display all mounted modules.
20. Call the code: is_loaded (module) to determine whether the module is loaded. In shell, the tab key completion feature is used to determine whether the module is loaded.
21. The main task of code server is to dynamically load and clear modules. You can use functions in the Code module to operate on the Code server and then manage and configure the system code library.
22. The code search path is the search path of the Code server load module. The default path includes the current path and the path of all database applications. Use code: get_path.
23. Erlang root directory: the Erlang installation directory. All database applications are under the lib directory of the root directory. You can view the root directory location through code: root_dir.
24. Several problems faced by hot upgrade: Upgrade steps are atomic, backward compatible in case of upgrade failure, and synchronization of upgrades in distributed environments. SASL application Library provides some hot upgrade tools.
25. The simplest hot upgrade is to reload the module. The prerequisite is that the upgrade does not modify the existing loop data.
26. Since a function is also a type of data, it can also be part of a tuple, a part of a record, or be sent as a message. Of course, the return value of other functions is nothing strange, so that you can dynamically create a function at runtime.
27. Reference data: in a distributed environment, reference data provides a unique identifier (TAG) across processes. It is mainly used for comparison and is more relevant to message transmission.
28. Bind a function defined in the module with a variable: fun1 = fun module: function/Arity
29. When passing a function to a remote node, it is clear that the modules called in the function must also be in the Code Search Path of the remote node.
30. A binary is a reference to a non-typed memory. It was initially used by Erlang to Load Code through the network and then applied to socket-based communication.
31. The match operation of ETS may damage the real-time performance of the Erlang system: this is because all the match operations are implemented as bif, and the execution of BIF is atomic, when performing the match operation on a large ETS table, you need to traverse the complete ETS table, which will block other processes. To avoid such problems, we recommend that you use first and next to traverse the ETS table, which may be slower, but at least will not damage the system's real-time performance.
32. You must specify the key location for storing record data with ETS, because the first element of the record's tuple is always the same.
33. An Erlang node refers to the running Erlang runtime system. An alive Erlang node is a node that "can" communicate with other nodes. The alive node must have a name. Call Erlang: is_alive () to determine whether the current node is alive. The net_kernel module provides functions to control the alive of the Erlang node.
34. Alive Erlang nodes have two types of names: short name (short name) and long name (Long Name). Short Name nodes can only communicate with Short Name nodes, and Long Name nodes can only communicate with Long Name nodes.
35. The security concept of the Erlang system is: either trust you completely or trust you completely. Therefore, the interconnected remote Erlang node has all the access permissions of the local node. For Erlang nodes distributed on the Internet, you can use SSL to enhance security.
36. Inter-node security is controlled through cookies. Each node holds an atom called secret cookie, and nodes with the same cookie can communicate with each other. (The home directory contains a ". Erlang. Cookie" file whose content is the default cookie value .) In addition, you can set cookies temporarily to allow nodes with different cookies to communicate with each other.
37. The interconnection between distributed nodes is implemented through the net_kernel process on each node, and the remote start of the process is also the responsibility of net_kernel. The net_kernel process uses cookies for security authorization. Therefore, you can modify net_kernel to customize your own security authorization mechanism.
38. For distributed systems with too many Erlang nodes, one problem is that there will be too many TCP/IP connections. If there are n nodes that are connected to each other, there will be n * (N-1) /2 TCP/IP connections. The solution is hidden node.
39. View hidden nodes through node (hidden) or node (connected)
40. One usage of the hidden node is to connect many small distributed clusters as a "Gateway. Another usage is maintenance, which does not affect traffic.
41. The general message sending format is PID! Message: {register_name, node }! Message
42. The timeout of receive is troublesome because the message may arrive again after the timeout, and the message will accumulate in the mailbox of the receiving process. When the process enters the message receiving again, messages accumulated after timeout may be processed. Therefore, it is best to flush the mailbox of the process before receiving messages.
43. Monitor_node (remotenode, true) is used to monitor remote nodes. When a monitored remote node crashes, the monitoring process receives the {nodedown, remotenode} message.
44. You can use the BIF function node (ARG) to query the node on which a process (PID), reference, or port is located ).
45. EPMD is short for Erlang Port Mapper deamon. It is an operating system-level daemon and is part of the Erlang runtime system. No matter how many Erlang nodes are running, each computer runs only one EPMD. It starts with the first start of the Erlang node and does not end with the end of the Erlang node. EPMD monitors connection requests on port 4369 and maps them to the listening ports of the corresponding node.
46. EPMD can be started independently as a shell command. It also contains several parameters and can be viewed through EPMD-help. For example, you can view the ports occupied by all Erlang nodes.
47. An important use of EPMD is that the delay_accept and delay_write parameters can be used to simulate busy network conditions and facilitate testing.
48. OTP applications compiled by programmers are the bricks that constitute the Erlang system. The processes at runtime form a supervision tree. The OTP application itself is an OTP behavior.

Reprinted: http://cryolite.iteye.com/blog/419235