Skip to content
Back to top
View this page

# greenlet: Lightweight concurrent programming

What are greenlets?

greenlets are lightweight coroutines for in-process sequential concurrent programming.

greenlets can be used on their own, but they are frequently used with frameworks such as gevent to provide higher-level abstractions and asynchronous I/O.

greenlets are frequently defined by analogy to `threads` or Python’s built-in coroutines (generators and `async def` functions). The rest of this section will explore those analogies. For a more precise introduction, see greenlet Concepts.

See History And About for how the greenlet library was created, and its relation to other similar concepts.

Are greenlets similar to threads?

For many purposes, you can usually think of greenlets as cooperatively scheduled `threads`. The major differences are that since they’re cooperatively scheduled, you are in control of when they execute, and since they are coroutines, many greenlets can exist in a single native thread.

Beginning with greenlet 3.3, free-threaded builds of CPython are supported, but they have limited testing and some other limitations. For more on free-threading and greenlet, see Caveats and Known Issues.

How are greenlets different from threads?

Threads (in theory) are preemptive and parallel [1], meaning that multiple threads can be processing work at the same time, and it’s impossible to say in what order different threads will proceed or see the effects of other threads. This necessitates careful programming using `locks`, `queues`, or other approaches to avoid race conditions, deadlocks, or other bugs.

In contrast, greenlets are cooperative and sequential. This means that when one greenlet is running, no other greenlet can be running; the programmer is fully in control of when execution switches between greenlets. This can eliminate race conditions and greatly simplify the programming task.

Also, threads require resources from the operating system (the thread stack, and bookkeeping in the kernel). Because greenlets are implemented entirely without involving the operating system, they can require fewer resources; it is often practical to have many more greenlets than it is threads.

Beginning with greenlet 3.3, you can combine threads and greenlets on free-threaded builds of CPython to take advantage of the strengths of both, but there may be limitations. See Caveats and Known Issues.

How else can greenlets be used?

greenlets have many uses:

- They can be treated like cooperative threads. You can implement any scheduling policy you desire.

- Because greenlets work well with C libraries (greenlets can switch even with C functions in the call stack), they are well suited for integrating with GUIs or other event loops.

  gevent is an example of using greenlets to integrate with IO event loops (libev and libuv) to provide a complete asynchronous environment using familiar programming patterns.

- Similar to the above, greenlets can be used to transform apparently asynchronous tasks into a simple synchronous style. See Motivation: Treating an Asynchronous GUI Like a Synchronous Loop for an example of writing an asynchronous event-driven GUI app in a simple synchronous style.

- In general, greenlets can be used for advanced control flow. For example, you can create generators—without the use of the `yield` keyword!

Are greenlets similar to generators? What about asyncio?

All three of greenlets, generators, and asyncio use a concept of coroutines. However, greenlets, unlike the other two, require no special keywords or support from the Python language. In addition, greenlets are capable of switching between stacks that feature C libraries, whereas the other two are not.

Footnotes

[1]

In CPython, the global interpreter lock (GIL) generally prevents two threads from executing Python code at the same time. Parallelism is thus limited to code sections that release the GIL, i.e., C code.

## Indices and tables

- Search Page

- Index

- Module Index