Erlang Behaviours: Programming with Process Design Patterns

Abstract

Erlang processes run independently of each other, each using separate memory and communicating with each other by message passing. These processes, while executing different code, do so following a number of common patterns. By examining different examples of Erlang-style concurrency in client/server architectures, we identify the generic and specific parts of the code and extract the generic code to form a process skeleton. In Erlang, the most commonly used patterns have been implemented in library modules, commonly referred to as OTP behaviours. They contain the generic code framework for concurrency and error handling, simplifying the complexity of concurrent programming and protecting the developer from many common pitfalls.

Trace Partitioning and Local Monitoring for Asynchronous Components

“…We demonstrate the implementability of our local monitoring approach by considering actors in Erlang [3,9] which constitute an instance of asynchronous component systems. Erlang is a general-purpose, concurrent programming language where actors are concurrent units of decomposition that do not share any mutable memory.…”

“…Tracing via the EVM [9] makes it possible to observe actor behaviour without modifying the system through commonly used instrumentation techniques such as AspectOriented Programming (AOP). It can be selectively applied to specific groups of actors simultaneously, enabling one to independently target different subparts of the system and attain partitioned traces as described in Sec.…”

Runtime Adaptation for Actor Systems

“…E.g., for any environment, we cannot typecheck the erroneous script ϕ from Ex. 4 -with the necessary type annotations as in (9). Similarly, we cannot typecheck the script below (mentioned earlier in Ex.…”

“…Actor systems [2,14,9] consist of independently-executing components called actors. Every actor is uniquely-identifiable, has its own local memory, and can either spawn other actors or interacting with them through asynchronous messaging.…”

“…1 Actors are often used to build service-oriented systems with limited downtime [3,14]. Coding practices such as fail-fast design-patterns [9,14] already advocate for a degree of RA for building robust, fault-tolerant systems: through mechanisms such as process linking and supervision trees, crashed actors are detected by supervisor actors, which respond through adaptations such as restarting the actors, replacing them with limp-home surrogate actors, or killing further actors that may potentially be affected by the crash.…”