Introduction to the use of Python greenlet and analysis of its implementation principles

Recently started to study Python's parallel development technology, including multi-threading, multi-process, coroutine, etc. I gradually sorted out some information on the Internet, and today I sorted out the information related to greenlet.

Technical background of concurrent processing

Parallel processing is currently receiving great attention, because in many cases, parallel computing can greatly improve system throughput, especially in the current era of multi-core and multi-processors. Therefore, ancient languages ​​like lisp have been picked up again, and functional programming has become more and more popular. Introducing a library for parallel processing in python: greenlet. Python has a very famous library called stackless, which is used for concurrent processing. It mainly uses a micro-thread called tasklet. The biggest difference between greenlet and stackless is that it is very lightweight? Not enough. The biggest difference is that greenlet requires you to handle thread switching yourself. That is to say, you need to specify which greenlet to execute now and which greenlet to execute again.

Implementation mechanism of greenlet

In the past, python was used to develop web programs, and the fastcgi mode was always used. Then multiple threads were started in each process for request processing. One problem here is that it needs Ensure that the response time of each request is very short, otherwise the server will refuse service as long as a few more slow requests are made, because no thread can respond to the request. Usually, our services will be tested for performance when they go online, so under normal circumstances, there is not much Big problem. But it is impossible to test all scenarios. Once it occurs, the user will wait for a long time without responding. Some parts are unavailable, which leads to all unavailability. Later, it was converted to coroutine, greenlet under python. So I made an implementation mechanism of it. Simple understanding.

Each greenlet is just a python object (PyGreenlet) in the heap. So it is no problem for you to create millions or even tens of millions of greenlets for a process.

typedef struct _greenlet {
	PyObject_HEAD
	char* stack_start;
	char* stack_stop;
	char* stack_copy;
	intptr_t stack_saved;
	struct _greenlet* stack_prev;
	struct _greenlet* parent;
	PyObject* run_info;
	struct _frame* top_frame;
	int recursion_depth;
	PyObject* weakreflist;
	PyObject* exc_type;
	PyObject* exc_value;
	PyObject* exc_traceback;
	PyObject* dict;
} PyGreenlet;

Every A greenlet is actually a function, and the context that saves the execution of this function. For a function, the context is its stack. All greenlets in the same process share a common user stack allocated by the operating system. So at the same time, only Greenlets with stack data that do not conflict use this global stack. Greenlets save the bottom and top of their stacks through stack_stop and stack_start. If the stack_stop of the greenlet to be executed overlaps with the greenlet currently in the stack, The stack data of these overlapping greenlets should be temporarily saved to the heap. The saved location is recorded through stack_copy and stack_saved, so that the stack_stop and stack_start locations in the stack can be copied from the heap back to the stack during recovery. Otherwise, the stack data will appear. will be destroyed. Therefore, these greenlets created by the application achieve concurrency by continuously copying data to the heap or from the heap to the stack. It is really comfortable to use coroutine for IO-type applications.

The following is a simple stack space model of greenlet (from greenlet.c)

A PyGreenlet is a range of C stack addresses that must be
saved and restored in such a way that the full range of the
stack contains valid data when we switch to it.

Stack layout for a greenlet:

               |     ^^^       |
               |  older data   |
               |               |
  stack_stop . |_______________|
        .      |               |
        .      | greenlet data |
        .      |   in stack    |
        .    * |_______________| . .  _____________  stack_copy + stack_saved
        .      |               |     |             |
        .      |     data      |     |greenlet data|
        .      |   unrelated   |     |    saved    |
        .      |      to       |     |   in heap   |
 stack_start . |     this      | . . |_____________| stack_copy
               |   greenlet    |
               |               |
               |  newer data   |
               |     vvv       |

The following is a simple greenlet code.

from greenlet import greenlet

def test1():
    print 12
    gr2.switch()
    print 34

def test2():
    print 56
    gr1.switch()
    print 78

gr1 = greenlet(test1)
gr2 = greenlet(test2)
gr1.switch()

The coroutine currently discussed is generally It is supported by programming languages. At present, the languages ​​​​that I know that provide coroutine support include python, lua, go, erlang, scala and rust. The difference between coroutines and threads is that coroutines are not switched by the operating system, but by programmer coding. In other words, the switching is controlled by the programmer, so there is no so-called thread. Security Question.

All coroutines share the context of the entire process, so the exchange between coroutines is also very convenient.

Compared with the second solution (I/O multiplexing), programs written using coroutines will be more intuitive, rather than splitting a complete process into multiple managed event handlers. . The disadvantage of coroutines may be that they cannot take advantage of multi-core, but this can be solved by coroutines + processes.

Coroutines can be used to handle concurrency to improve performance, and can also be used to implement state machines to simplify programming. I use the second one more. I came into contact with python at the end of last year and learned about the coroutine concept of python. Later, I came into contact with yield processing through pycon china2011. Greenlet is also a coroutine solution, and in my opinion it is a more usable solution, especially for processing state machines.

At present, this part has been basically completed. I will take the time to summarize it later.

To summarize:

1) Multiple processes can take advantage of multi-core, but inter-process communication is troublesome. In addition, an increase in the number of processes will cause performance degradation and the cost of process switching is higher. Program flow complexity is lower than I/O multiplexing.

2) I/O multiplexing processes multiple logical processes within a process without process switching. The performance is high, and information sharing between processes is simple. However, the advantages of multi-core cannot be used. In addition, the program flow is cut into small pieces by event processing, making the program more complex and difficult to understand.

3) Threads run within a process and are scheduled by the operating system. The switching cost is low. In addition, they share the virtual address space of the process, and it is simple to share information between threads. However, thread safety issues lead to a steep learning curve for threads and are error-prone.

4) Coroutines are provided by programming languages ​​and are switched under the control of programmers, so there are no thread safety issues and can be used to handle state machines, concurrent requests, etc. But cannot take advantage of multi-core.

The above four solutions can be used together. I am more optimistic about the process + coroutine model

The above is the detailed content of Introduction to the use of Python greenlet and analysis of its implementation principles. For more information, please follow other related articles on the PHP Chinese website!