gevent is a coroutine-based Python networking library.
gevent runs on Python 2.6, 2.7, 3.3 and 3.4 and requires
pip install greenlet.
gevent also runs on PyPy 2.5.0 and 2.6.0, although 2.7.0 is recommended. On PyPy, there are no external dependencies.
The following example shows how to run tasks concurrently.
>>> import gevent >>> from gevent import socket >>> urls = ['www.google.com', 'www.example.com', 'www.python.org'] >>> jobs = [gevent.spawn(socket.gethostbyname, url) for url in urls] >>> gevent.joinall(jobs, timeout=2) >>> [job.value for job in jobs] ['184.108.40.206', '220.127.116.11', '18.104.22.168']
After the jobs have been spawned,
gevent.joinall() waits for
them to complete, allowing up to 2 seconds. The results are
then collected by checking the
gevent.socket.gethostbyname() function has the same
interface as the standard
socket.gethostbyname() but it does not
block the whole interpreter and thus lets the other greenlets proceed
with their requests unhindered.
The example above used
gevent.socket for socket operations. If the standard
module was used the example would have taken 3 times longer to complete because the DNS requests would
be sequential (serialized). Using the standard socket module inside greenlets makes gevent rather
pointless, so what about modules and packages that are built on top of
That’s what monkey patching is for. The functions in
replace functions and classes in the standard
socket module with their cooperative
counterparts. That way even the modules that are unaware of gevent can benefit from running
in a multi-greenlet environment.
>>> from gevent import monkey; monkey.patch_socket() >>> import urllib2 # it's usable from multiple greenlets now
When monkey patching, it is recommended to do so as early as possible in the lifetime of the process. If possible, monkey patching should be the first lines executed.
Unlike other network libraries, in similar fashion to eventlet, gevent starts
the event loop implicitly in a dedicated greenlet. There’s no
you must call a
dispatch() function on. When a function from
gevent’s API wants to block, it obtains the
gevent.hub.Hub instance — a greenlet
that runs the event loop — and switches to it. If there’s no
instance yet, one is created on the fly.
The event loop provided by libev uses the fastest polling mechanism available on the system by default. Please read the libev documentation for more information.
The Libev API is available under
gevent.core module. Note, that
the callbacks supplied to the libev API are run in the
greenlet and thus cannot use the synchronous gevent API. It is possible to
use the asynchronous API there, like
The greenlets all run in the same OS thread and are scheduled
cooperatively. This means that until a particular greenlet gives up
control, (by calling a blocking function that will switch to the
gevent.hub.Hub), other greenlets won’t get a chance to run. This is
typically not an issue for an I/O bound app, but one should be aware
of this when doing something CPU intensive, or when calling blocking
I/O functions that bypass the libev event loop.
Even some apparently cooperative functions, like
gevent.sleep(), can temporarily take priority over
waiting I/O operations in some circumstances.
Synchronizing access to objects shared across the greenlets is
unnecessary in most cases (because yielding control is usually
lock.Semaphore classes, although present, aren’t used very
often. Other abstractions from threading and multiprocessing remain
useful in the cooperative world:
The greenlets are spawned by creating a
gevent.Greenlet instance and calling its
gevent.spawn() function is a shortcut that does exactly that). The
method schedules a switch to the greenlet that will happen as soon as the current greenlet gives up control.
If there is more than one active greenlet, they will be executed one by one, in an undefined order.
If there is an error during execution it won’t escape the greenlet’s boundaries. An unhandled error results in a stacktrace being printed, annotated by the failed function’s signature and arguments:
>>> gevent.spawn(lambda : 1/0) >>> gevent.sleep(1) Traceback (most recent call last): ... ZeroDivisionError: integer division or modulo by zero <Greenlet at 0x7f2ec3a4e490: <function <lambda...>> failed with ZeroDivisionError
The traceback is asynchronously printed to
sys.stderr when the greenlet dies.
Greenlet instances have a number of useful methods:
join– waits until the greenlet exits;
kill– interrupts greenlet’s execution;
get– returns the value returned by greenlet or re-raised the exception that killed it.
It is possible to customize the string printed after the traceback by subclassing the
and redefining its
To subclass a
gevent.Greenlet, override its
gevent.Greenlet._run() method and call
class MyNoopGreenlet(Greenlet): def __init__(self, seconds): Greenlet.__init__(self) self.seconds = seconds def _run(self): gevent.sleep(self.seconds) def __str__(self): return 'MyNoopGreenlet(%s)' % self.seconds
Greenlets can be killed asynchronously. Killing will resume the sleeping greenlet, but instead
of continuing execution, a
gevent.greenlet.GreenletExit will be raised.
>>> g = MyNoopGreenlet(4) >>> g.start() >>> g.kill() >>> g.dead True
gevent.greenlet.GreenletExit exception and its subclasses are handled differently than other exceptions.
gevent.greenlet.GreenletExit is not considered an exceptional situation, so the traceback is not printed.
gevent.greenlet.GreenletExit is returned by
get as if it were returned by the greenlet, not raised.
kill method can accept a custom exception to be raised:
>>> g = MyNoopGreenlet.spawn(5) # spawn() creates a Greenlet and starts it >>> g.kill(Exception("A time to kill")) Traceback (most recent call last): ... Exception: A time to kill MyNoopGreenlet(5) failed with Exception
kill can also accept a timeout
argument specifying the number of seconds to wait for the greenlet to
exit. Note, that
kill cannot guarantee
that the target greenlet will not ignore the exception (i.e., it might
catch it), thus it’s a good idea always to pass a timeout to
The exact timing at which an exception is raised within a
target greenlet as the result of
kill is not defined. See that function’s
documentation for more details.
Many functions in the gevent API are synchronous, blocking the current
greenlet until the operation is done. For example,
kill waits until the target greenlet is
gevent.greenlet.Greenlet.dead before returning . Many of
those functions can be made asynchronous by passing the argument
Furthermore, many of the synchronous functions accept a timeout
argument, which specifies a limit on how long the function can block
gevent.event.AsyncResult.get(), and many more).
SSLObject instances can also have a timeout, set by the
When these are not enough, the
gevent.timeout.Timeout class can be used to
add timeouts to arbitrary sections of (cooperative, yielding) code.
Gevent comes with TCP/SSL/HTTP/WSGI servers. See Implementing servers.
Next page: What’s new in gevent 1.1