Looking at Ching see from the Erlang process

Looking at Ching see from the Erlang process

After the multi-core slowly fire, the co-process class programming also began to become more and more fire. There are more representative goroutine of Go, Erlang in Erlang, Scala actor, fibre under Windows, and some dynamic languages like Python, Ruby, and Lua are also slowly supporting the process.

In fact, we have heard a lot about the association of many nouns, the following roughly to explain:

• OS processes: processes are the smallest unit of resource management, including process Control blocks (PCBS), program segments, data segments
• OS thread: a thread is the smallest unit of execution of a program, consisting of a thread ID, the current instruction pointer (PC), a register set and a stack, and the need for context and stack switching in the kernel state when switching between kernel threads.
• lightweight process (LWP): A high-level abstraction based on kernel threads, with each LWP corresponding to an actual thread. The advantage is that in some cases there is no need to create a new actual process that much overhead.
• co-process: in different programming languages or libraries because of the difference in implementation, also called Fiber, actor and so on. It can actually be understood as an application-level thread whose scheduler is not the CPU of the kernel, but rather the VM-level scheduler implemented by the user level.

In other words, the process has the following characteristics:

1. The switchover of concurrent concurrency is basically switched at the user state level without triggering the kernel and reducing system overhead
2. Although the process is actually definitely executed on an OS thread, how it executes, when it executes, and on which thread it executes is determined by the user's scheduler, which means that the users of the process do not have to care about the underlying thread.
3. As the user level exists, the process is actually a function to be executed, the cost of creating the destruction is very small, and because the switch is basically in the user state, it is easy to open the millions in one session.

We can call it a co-process (Coroutine), which basically satisfies the above characteristics.

But different languages have different implementations, including the actor model, which is represented by Erlang, and the coroutine represented by go.

Go is not familiar, but the main is the communication between the process and yield initiative to let the CPU operation, which in Python, Ruby and so also implemented.

Erlang and Scala mainly take an actor model, also called actor-oriented programming. Mainly follow the following characteristics:

1. The idea of all actors is that every performer is an actor. (a bit like Java each of the feature holders is an object class)
2. Actors can only be allowed to communicate via messaging, do not share memory, and message delivery has no side effects (no side effects are plagued by problems such as dirty reading or modification).
3. The actor's send and receive message is asynchronous, and the received message is generally a copy.

From his features, actor is a more thorough concurrency-oriented programming model than normal coroutine. When designing the Actor model program, developers need to consider how to use concurrency features to make their programs more concurrent, without having to consider locks, conflicts, inconsistencies, and so on.

Looking at Ching see from the Erlang process