(1) Erlang/OTP NODES are : named virtual machines, in a distributed network of such nodes.
(2) Erlang/OTP MODULES are : encapsulations for Erlang instructions ("code"), which may be loaded onto NODES. MODULES can be VERSIONED, and VERSIONS may be hot-code-swapped on a NODE. A NODE can have only TWO VERSIONS of a a MODULE.
(3) Erlang/OTP PROCESSES are : userspace runtime processes, executing on NODES, reifying Erlang code which may or may not have been encapsulated in a MODULE. ( The availability of [erl_parse, erl_eval] provides a side-channel for loading non-MODULE code. )
(3.1.) PROCESSES persist, even when their calling & called-into MODULES are VERSION-swapped. If a PROCESS has called into VERSION (N) of a MODULE, but not yet called into VERSION (N+1), and if the NODE loads VERSION (N+2), then the PROCESS will be killed. ( PROCESSES cannot skip upgrades to their runtimes : going from VERSIONS (N) to (N+2) is not allowed. )
(4) C-nodes : a C program running independently, can present itself as a NODE, using well-documented protocols. ( Therefore it seems reasonable that C middleware could wrap any other system that wants to present as a NODE. ) This is the loose coupling.
(5) Native Implemented Functions ( NIFs ): a compiled C library, can be linked into MODULES, and thus called by PROCESSES. This is the tight coupling.
(5.1.) When a NODE loads a MODULE, it initiates all that MODULE's NIFs within the NODE's own operating system process ( thus making the NODE susceptible to memory leakage and/or corruption introduced by the NIF ).
(5.2.) An NIF is initialised ONCE by a NODE, regardless of how many MODULES on that NODE link into the NIF. So, an NIF's static variables may introduce persistent storage in memory, for the lifetime of the NODE. This introduces shared memory, between every PROCESS that calls the NIF, via any MODULE on the NODE which links into the same NIF, weakening the NODE's "shared-nothing" protocol guarantees for PROCESSES. The NIF's is evacuated by the NODE, only if/when its calling MODULE is evacuated by the NODE ... NIFs should take precautions to clean up their own C-based memory allocations, as there is no way for NODE to do so.
2025-04-25 : So somewhere around the time they started releasing JIT ( about half a decade ago ) they separately released this workflow + tooling to make any linked C code "more Erlang".
Erlang's preemptive scheduling : enforces round-robbin CPU time-sharing for VM bytecode, but it can't for linked C code ( requires kernel mode privileges, which the VM doesn't have ).
Random C code that's linked to Erlang code may not have been written as coroutines, thus potentially blocking linked Erlang code.
So Erlang ships with an additive compiler that adds "yielding" to C functions, and a guide for debugging the transformed C.
https://www.erlang.org/doc/apps/erts/automaticyieldingofccode.html
https://www.linkedin.com/pulse/til-erlang-c-code-can-interact-following-ways-yangjerng-hwa-hmx5c/
No comments :
Post a Comment