The application of the co-process in the Web server (with a good picture)

Co-process (fiber, micro-threading) This concept has long been, the Internet companies have also studied, but in the domestic major forums and the conference hot up, or this year's events.

Recently involved in the discussion of open platform construction and architecture design, some colleagues mentioned that using the co-process instead of threading can greatly improve performance. This has led to great interest and intense discussion among our team.

First, explain what is the association process.

The process is a user-state thread. Traditional on-line switching is controlled by the operating system, and each switchover involves a context-saving switchover and the process of switching between the user state and the kernel state. The handoff of the co-process is controlled by the user, and each switch involves only the context saving and switching (that is, the stack's stack and the process of the stack). Because there may be multiple threads working on the same resource, using a thread requires a "wait-locking-release" set of actions if necessary. There is no problem with simultaneous operation of the same resource in the same thread, because all the threads in the same thread are serially executed. This, of course, also leads to the problem that a program that is architected on multiple threads in the same thread cannot take advantage of multicore resources. Finally, there is a benefit to the process that the process can produce more readable code.

after proposing the co-process, I also offer several other concepts that can be compared. Process, thread, callback.
Processes and threads are not much to say. Understand that a process contains one or more threads, and one thread contains one or more co-processes. In Linux, the resources that are consumed by creating processes and threads are consistent.
The callback is highlighted here. The callback function does not cause the context to be saved and toggled relative to the process, so the switchover is the fastest, but it also causes problems with no context using the callback function. When context is needed, it can only be saved using global variables, which do not conform to the programming habits of most programmers.

then, describe what caused the problem that we found to be in need of the process.
In high-concurrency applications, especially Web applications, each server has more than n connections and logical processing, and there is no logical association between each connection. Traditionally, for each connection request, a process or thread was created to handle the request (a bit more advanced would use pooled technology), so that if a processing thread of a certain type of request caused the processing to take too long due to a variety of problems, the problem would be very serious due to the time slice being consumed on this thread, because a Causes all requests to become slow or unavailable.
We hope that when a request has a problem, no other requests will be affected.

Purely to partition the request type, different threads to handle the different requests can solve the problem, but there will be some CPU spent in processing a long time of the request, in addition, the replacement of the application, there will always be a lot of configuration even code-level updates, not the perfect solution.
Converting the synchronization process to async can, of course, resolve the issue. However, not all synchronization processes can be processed asynchronously.

How the process solves this problem.

The book "Windows core programming via/C + +" says: Fiber (the thread in Windows is called fiber fiber) is provided to make UNIX programs easier to port to Windows, and it is recommended that Windows developers do not use fiber. I think this is actually not all right, need to look at the scene. The author says not to use fiber because the context of the save and switch can be resolved by the thread and the callback function can solve the problem of switching within the same thread, without the need for locks, and faster. However, in high concurrency applications, it is not the same, in the face of callbacks need to use a programming complex state machine and desperate debugging, fiber context saving and switching is easy to replace these, and the implementation of the program is very clean and beautiful. This is the reason why we choose to use the co-process.

Of course, the problem is not the co-process can be solved. First, the combination of asynchronous IO is unavoidable. Next to any Web server, the backend has a lot of service. A request may involve multiple service. This requires the use of the furture mode, so that any request requires only one service that waits for the longest time without serial waiting for all the service. Again, more complicated is, for the scheduling of the process, we need to implement a scheduler, so that the call to the association, always can be dispatched to the request service completion of the process, but not the completion of the process, it will not be dispatched.

Combined with these design elements, a Web server using a co-process can work efficiently.

The application scenario of the co-process

http://blog.csdn.net/huyiyang2010/article/details/6042326

The application of the co-process in the Web server (with a good picture)