Within Erlang all communication is done by asynchronous signaling. The communication between an Erlang node and the outside world is done through a port. A port is an interface between Erlang processes and an external resource. In early versions of Erlang a port behaved very much in the same way as a process and you comunicated by sending and receiving signals. You can still communicate with ports this way but there are also a number of BIFs to communicate directly with a port.
In this chapter we will look at how ports are used as a common interface for all IO, how ports comunicate with the outside world and how Erlang processes comunicate with ports. But first we will look at how standard IO works on a higher level.
-
IO protocol
-
group leader
-
erlang:display — a biff that sends directly to node’s std out
-
io:format — sends through io protocol and the group leader
-
Redirecting standard IO at startup (detached mode)
-
Standard in and out
A port is the process like interface between Erlang processes and everything that is not Erlang processes. The programmer can to a large extent pretend that everything in the world behaves like an Erlang process and communicate through message passing.
Each port has an owner, more on this later, but all processes who knows about the port can send messages to the port. In figure REF we see how a processes can communicate with the port and how the port is communicating to the world outside the Erlang node.
+-------------------+
| __ |
| / \ owner __ _______
| \__/ < - -- -> / \ <----> / /
| P1 \__/ /______/
| 7 |Port1 file
| / |
| / |
| __ / |
| / \ |
| \__/ |
| P2 |
+-------------------+
Erlang Node
Process P1 has opened a port (Port1) to a file, and is the owner of
the port and can receive messages from the port. Process P2 also has a
handle to the port and can send messages to the port. The processes
and the port resides in an Erlang node. The file lives in the file and
operating system on the outside of the Erlang node.
If the port owner dies or is terminated the port is also killed. When a port terminates all external resources should also be cleaned up. This is true for all ports that comes with Erlang and if you implement your own port you should make sure it does this cleanup.
There are three different classes of ports: file descriptors, external programs and drivers. A file descriptor port makes it possible for a process to access an already opened file descriptor. A port to an external program invokes the external program as a separate OS process. A driver port requires a driver to be loaded in the Erlang node.
All ports are created by a call to erlang:open_port(PortName, PortSettings).
A file descriptor port is opened with {fd, In, Out} as the PortName. This class of ports is used by some internal ERTS servers like the old shell. They are considered to not be very efficient and hence seldom used.
An external program port can be used to execute any program in the native OS of the Erlang node. To open an external program port you give either the argument {spawn, Command} or {spawn_executable, FileName} with the name of the external program. This is the easiest and one of the safest way to interact with code written in other programming languages. Since the external program is executed in its own OS process it will not bring down the Erlang node if it crashes. (It can of course use up all CPU or memory or do a number of other things to bring down the whole OS, but it is much safer than a linked in driver or a NIF.)
A driver port requires that a driver program has been loaded with ERTS. Such a port is started with either {spawn, Command} or {spawn_driver, Command}. Writing your own linked in driver can be an efficient way to interface for example some C library code that you would like to use. Note that a linked in driver executes in the same OS process as the Erlang node and a crash in the driver will bring down the whole node. Details about how to write an Erlang driver in general can be found in [CH-C].
Erlang OTP comes with a number port drivers implementing the predefined port types. There are the common drivers available on all platforms: tcp_inet, udp_inet, sctp_inet, efile, zlib_drv, ram_file_drv, binary_filer, tty_sl. These drivers are used to implement e.g. file handling and sockets in Erlang. On Windows there is also a driver to access the registry: registrydrv. And on most platforms there are example drivers to use when implementing your own driver like: multi and sig_drv.
+-----------------------------------------------------------------------------------------------------+ | Entities on an Erlang Node | |--------------------------------------------------+--------------------------------------------------| | Processes | Ports | |--------------------------------------------------+---------++------++-------------------------------| | | FD || OS || Drivers | |--------------------------------------------------+---------++------++----------+++-------+++--------| | | (Heart) || (ls) || tcp_inet ||| efile ||| ... | +--------------------------------------------------+---------++------++----------+++-------+++--------+
Creating
Commands
Implementation
See chapter [CH-C] for details of how to implement your own linked in driver.