Read the documentation online at http://www.gevent.org.
Would be cool to have python3 support, ideally as single source.
Here's an old python3 fork: http://bitbucket.org/jjonte/gevent
Denis.Bilenko said, at 2011-01-28T05:36:07.000Z:
There's some work going on at https://bitbucket.org/Edmund_Ogban/gevent-py3k
[email protected] said, at 2011-03-20T18:40:50.000Z:
Exception handling is a problem here. With Python2.5 there is only except Exception, e, whereas Python3.x requires except Exception as e.
Making this single source supporting 2.5 and higher is therefore quite difficult. Or is there some future that can be used to simulate the new syntax included with the language since 2.6?
Otherwise I would say: drop support for Python 2.5 with the next release version, and make that one compatible with 2.6 .. 3.2.
anacrolix said, at 2011-09-13T00:03:14.000Z:
I'm keen to try gevent, but I sailed for Python3 over a year ago.
anacrolix said, at 2011-09-20T00:23:26.000Z:
Denis can you report on the status of Python3 support for gevent?
Denis.Bilenko said, at 2011-12-20T18:14:35.000Z:
Issue 89 has been merged into this issue.
luchenue said, at 2011-12-23T09:14:52.000Z:
Any news ?
anacrolix said, at 2011-12-23T11:09:10.000Z:
From what I've observed, I don't think Denis wants to break support for Python 2 yet, and so won't accept patches that don't support both 2 *and* 3, which is a complex obstacle.
k.cherkasoff said, at 2011-12-23T11:42:53.000Z:
Is there any up to date forks for python 3.x ?
whitelynx said, at 2012-02-01T07:13:18.000Z:
I think the general approach for maintaining anything that's supposed to work on 2.5 - 3.x is to use the 2to3 tool to automatically generate a python3 version from the python2 source. The exception handling issue mentioned by carsten above (comment 2) is treated by the 'except' fixer in 2to3. (http://docs.python.org/library/2to3.html?highlight=except#2to3fixer-except) Since fixers can be run individually, it shouldn't be too difficult to put together a 2to3 command line that would be able to translate gevent with a minimum amount of breakage, and then just manually clean up the results. I do wish there was a 3to2 or similar that would translate some of the python3-style idioms to something compatible with 2.5, as with the 'except _ as _' syntax.
amcnabb8 said, at 2012-02-09T19:14:00.000Z:
The six library makes it very easy to support both Python 2 (>=2.6) and Python 3 without needing 2to3. With a couple of workarounds, Michael Foord has shown that it's entirely possible to support Python 2.4 without 2to3. But really, it's not as hard as it sounds to support both Python 2 and 3, and there are two reasonable approaches.PyVer: python3
As per the discussions on #pypy @ irc.freenode.org, it's been reported that
pypycore runs successfully, with minor as of yet unfixed bugs, on PyPy 2.0 dev and is able to outperform
gevent on CPython in some benchmarks by a factor of 2.
So in general, could we hope for a future direction of the adaptations in
pypycore becoming an integral part of
gevent? Something comparable to how
gevent-zeromq has become part of
pyzmq in recent versions (http://zeromq.github.com/pyzmq/api/zmq.green.html#module-zmq.green).
This would, in the future, give us an awesome stack of gevent and ZeroMQ running on PyPy with the currently under development but functional JIT compilation support for
continulet based stacks (which include
stackless), easily on par in its potential with the success of Node.js.
greenlet always get their
finally block invoked for example when a
KeyboardInterrupt occurs. To reproduce:
import time, greenlet def bar(): try: greenlet.getcurrent().parent.switch() finally: print "CLEANUP BAR" def foo(): try: time.sleep(1.0) finally: print "CLEANUP FOO" b1 = greenlet.greenlet(bar) b1.switch() b2 = greenlet.greenlet(bar) b2.switch() greenlet.greenlet(foo).switch()
CLEANUP BAR + 1 x
CLEANUP FOO gets printed when
Ctrl-C is pressed during that
However, when using
time.sleep is used, for obvious reasons), no cleanup code gets invoked whatsoever when
Ctrl-C is pressed:
from gevent import spawn, sleep from gevent.event import Event def bar(): try: Event().wait() # just block and switch back to main finally: print "CLEANUP BAR" def foo(): try: sleep(1.0) finally: print "CLEANUP FOO" # this does get printed for obvious reasons if time.sleep is used instead gevent.joinall([spawn(bar), spawn(bar), spawn(foo)])
CLEANUP FOO nor
CLEANUP BAR gets printed.
This is both weird, because
greenlet already handles this automatically, as well as inconsistent with standard Python semantics, which I suppose should always be sticked to. Violating fundamental semantic guarantees of the language will eventually cause confusion and problems, or at least inconvenience, such as having to manually keep track of all spawned greenlets and to kill them in a global
finally cleanup block, or in a signal handler—i.e. stuff that should be expected from
(I've run the above code on OS X 10.7 and 64bit Python 2.7)
P.S. Also, an
except KeyboardInterrupt block never gets invoked either.
When using ctypes callbacks the documentation is as follows:
Also, note that if the callback function is called in a thread created outside of Python’s control (e.g. by the foreign code that calls the callback), ctypes creates a new dummy Python thread on every invocation. This behavior is correct for most purposes, but it means that values stored with threading.local will not survive across different callbacks, even when those calls are made from the same C thread.
I need to schedule the execution of the code inside the callback. The execution should happen in the Hub with which the callback has been created in the first place. The "dummy thread" however, is an actual physical pseudo-Python thread, even if Gevent monkey-patched the threading module beforehand.
When registering a callback I can capture the
hub from the current gevent thread.
Is there a safe way to inject a Greenlet into a hub i.e. something like
gevent.spawn() whilst passing the Hub to the spawn from a different physical thread the same way as
loop.call_soon_threadsafe works in asyncio? (https://docs.python.org/3/library/asyncio-eventloop.html#asyncio.AbstractEventLoop.call_soon_threadsafe)?
I am trying to run a socket server with ssl support. For this purpose I am usung flask-socketio which uses gevent behind. I think flask-socketio has nothing to do with ssl options, it is just passing to ssl configurations to gevent init.
Socket server with ssl support was possible, but after re-installing all the pip packages, I started to get the following error.
Traceback (most recent call last): File "/usr/local/lib/python2.7/dist-packages/gevent/greenlet.py", line 327, in run result = self._run(*self.args, **self.kwargs) File "/usr/local/lib/python2.7/dist-packages/gevent/server.py", line 102, in wrap_socket_and_handle ssl_socket = self.wrap_socket(client_socket, **self.ssl_args) File "/usr/local/lib/python2.7/dist-packages/gevent/_ssl2.py", line 410, in wrap_socket ciphers=ciphers) File "/usr/local/lib/python2.7/dist-packages/gevent/_ssl2.py", line 93, in __init__ self.do_handshake() File "/usr/local/lib/python2.7/dist-packages/gevent/_ssl2.py", line 310, in do_handshake return self._sslobj.do_handshake() SSLError: [Errno 8] _ssl.c:510: EOF occurred in violation of protocol <Greenlet at 0x7fbc02c4a9b0: <bound method WSGIServer.wrap_socket_and_handle of <WSGIServer at 0x7fbc03b9b110 fileno=9 address=0.0.0.0:5000>>(<socket at 0x7fbc02bf7590 fileno=76 sock=10.122.97, ('188.8.131.52', 40471))> failed with SSLError
is there any solution?Type: Bug PyVer: python3
In fact it removes many of the SSLv3-related constants, including
ROTOCOL_SSLv3, which make gevent fail with a message similar to this:
File "<whatever>/h/local/lib/python2.7/site-packages/gevent/ssl.py", line 386, in <module> def get_server_certificate(addr, ssl_version=PROTOCOL_SSLv3, ca_certs=None): NameError: name 'PROTOCOL_SSLv3' is not defined
One could argue that it's not nice for a distribution to haphazardly remove constants that are still there in the upstream version, but these things happen, so... maybe gevent could do something about this? (Like, maybe, move to 'PROTOCOL_SSLv23' instead?)
I haven't encountered this directly, but have now had a couple of New Relic Python agent users raise the problem with us.
The problem is that in the Python subprocess module it has:
import select _has_poll = hasattr(select, 'poll')
Thus _has_poll will only be true if poll() exists in the select module.
Later it has:
if _has_poll: stdout, stderr = self._communicate_with_poll(input) else: stdout, stderr = self._communicate_with_select(input)
and then in _communicate_with_poll() it has:
poller = select.poll()
The problem is that in gevent monkey patching it will remove the poll() function from the select module.
def patch_select(aggressive=True): """Replace :func:`select.select` with :func:`gevent.select.select`. If aggressive is true (the default), also remove other blocking functions the :mod:`select`. """ patch_module('select') if aggressive: select = __import__('select') # since these are blocking we're removing them here. This makes some other # modules (e.g. asyncore) non-blocking, as they use select that we provide # when none of these are available. remove_item(select, 'poll') remove_item(select, 'epoll') remove_item(select, 'kqueue') remove_item(select, 'kevent')
The end result is that if the subprocess module had been imported prior to gevent doing any monkey patching, then gevent is breaking the subprocess module as it has cached that the poll() function existed.
You therefore get:
File "/usr/lib/python2.7/subprocess.py", line 799, in communicate return self._communicate(input) File "/usr/lib/python2.7/subprocess.py", line 1401, in _communicate stdout, stderr = self._communicate_with_poll(input) File "/usr/lib/python2.7/subprocess.py", line 1431, in _communicate_with_poll poller = select.poll() AttributeError: 'module' object has no attribute 'poll'
If gevent is going to remove the poll() function, it should perhaps update the subprocess module and set _have_poll to False to avoid the problem.
One could argue gevent shouldn't need to consider that other modules have cached stuff from the select module, but since subprocess is part of the standard library, may be prudent to consider addressing the problem.
I don't know if this is a gevent issue or not. On AppVeyor (a Windows CI service), I used to be able to install coverage.py and its gevent dependency just fine (ignore 2.6 for the moment): https://ci.appveyor.com/project/nedbat/coveragepy/build/default-280
Then recently (in the last week), the builds started failing for everything, because Cython wasn't available: https://ci.appveyor.com/project/nedbat/coveragepy/build/default-285
It looks like gevent requires Cython at install time, but only declares that in certain circumstances. I don't see how that has changed recently, but something has.
Can you help?
Error Message (Complete build output in build.txt) :
/usr/bin/clang -Wno-unused-result -Wsign-compare -Wunreachable-code -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -pipe -Os -I/opt/local/include -I/opt/local/include -DLIBEV_EMBED=1 -DEV_COMMON= -DEV_CLEANUP_ENABLE=0 -DEV_EMBED_ENABLE=0 -DEV_PERIODIC_ENABLE=0 -DEV_USE_REALTIME=1 -DEV_USE_MONOTONIC=1 -DEV_USE_FLOOR=1 -Isrc/gevent/libev -I/opt/local/Library/Frameworks/Python.framework/Versions/3.9/include/python3.9 -I/private/var/folders/84/d3kmlqs95v78tgttk8pknqh80000gp/T/pip-install-ko7s16ut/gevent_4e61ae38b21f4cc085d31587063bc910/deps -I/private/var/folders/84/d3kmlqs95v78tgttk8pknqh80000gp/T/pip-install-ko7s16ut/gevent_4e61ae38b21f4cc085d31587063bc910/src/gevent/libev -I/private/var/folders/84/d3kmlqs95v78tgttk8pknqh80000gp/T/pip-install-ko7s16ut/gevent_4e61ae38b21f4cc085d31587063bc910/deps/libev -Isrc/gevent -Isrc/gevent/libev -Isrc/gevent/resolver -I. -I/Users/yves/.virtualenvs/passages/include -I/opt/local/Library/Frameworks/Python.framework/Versions/3.9/include/python3.9 -c src/gevent/libev/corecext.c -o build/temp.macosx-10.11-x86_64-3.9/src/gevent/libev/corecext.o -Wno-unreachable-code -Wno-deprecated-declarations -Wno-incompatible-sysroot -Wno-tautological-compare -Wno-implicit-function-declaration -Wno-unused-value -Wno-macro-redefined In file included from src/gevent/libev/corecext.c:872: In file included from src/gevent/libev/libev.h:9: /private/var/folders/84/d3kmlqs95v78tgttk8pknqh80000gp/T/pip-install-ko7s16ut/gevent_4e61ae38b21f4cc085d31587063bc910/deps/libev/ev.c:4105:34: error: use of undeclared identifier 'have_monotonic' if (ecb_expect_true (have_monotonic)) ^ 1 error generated. error: command '/usr/bin/clang' failed with exit code 1 ---------------------------------------- ERROR: Failed building wheel for gevent Failed to build gevent ERROR: Could not build wheels for gevent which use PEP 517 and cannot be installed directly [build.txt](https://github.com/gevent/gevent/files/5863150/build.txt)
Thanks !Platform: POSIX Platform: Unsupported environment
osx 10.11.1 , install gevent , i get an error ,
sudo -H pip install greenlet could not create '/System/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7/greenlet': Operation not permitted
i am is root , but ,why can't Operation not permitted ?
here is the detail message:
Status: not gevent
HackedBy007:~ weirdbird007$ sudo -H pip install greenlet Password: Collecting greenlet Using cached greenlet-0.4.9.tar.gz Installing collected packages: greenlet Running setup.py install for greenlet Complete output from command /usr/bin/python -c "import setuptools, tokenize;__file__='/private/tmp/pip-build-6KNYrr/greenlet/setup.py';exec(compile(getattr(tokenize, 'open', open)(__file__).read().replace('\r\n', '\n'), __file__, 'exec'))" install --record /tmp/pip-brHEyp-record/install-record.txt --single-version-externally-managed --compile: running install running build running build_ext building 'greenlet' extension creating build creating build/temp.macosx-10.11-intel-2.7 cc -fno-strict-aliasing -fno-common -dynamic -arch i386 -arch x86_64 -g -Os -pipe -fno-common -fno-strict-aliasing -fwrapv -DENABLE_DTRACE -DMACOSX -DNDEBUG -Wall -Wstrict-prototypes -Wshorten-64-to-32 -DNDEBUG -g -fwrapv -Os -Wall -Wstrict-prototypes -DENABLE_DTRACE -arch i386 -arch x86_64 -pipe -I/System/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7 -c greenlet.c -o build/temp.macosx-10.11-intel-2.7/greenlet.o creating build/lib.macosx-10.11-intel-2.7 cc -bundle -undefined dynamic_lookup -arch i386 -arch x86_64 -Wl,-F. build/temp.macosx-10.11-intel-2.7/greenlet.o -o build/lib.macosx-10.11-intel-2.7/greenlet.so running install_lib copying build/lib.macosx-10.11-intel-2.7/greenlet.so -> /Library/Python/2.7/site-packages running install_headers creating /System/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7/greenlet error: could not create '/System/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7/greenlet': Operation not permitted ----------------------------------------
Python Version : 3.7.3 IDE : pycharm problems : I make a speed testing. I am trying to read the local file whihc are more then 2000 , it took for 6.5 seconds when i use the gevent moulde, another took for 2.8 seconds when normally i used 'for in'. I want to know why does not gevent raise efficiency for I/O.Type: Question
It seems that there is a bug in
gevent.select.select on windows. After a socket read all data from its peer, and run
select.select again against it, it is still returned as readable, but in fact there is no data in buffer, and a following
.recv() will lead to blocking.
import gevent import gevent.monkey gevent.monkey.patch_all() import gevent.socket import gevent.select server = gevent.socket.socket() server.bind(('127.0.0.1', 12345)) server.listen(5) def socket_proc(socket): data = b'' while True: r, w, x = gevent.select.select([socket, ], , [socket, ], timeout=0.1) if r: data += socket.recv(1024) else: if data: socket.send((u'%s\n' % len(data)).encode('utf-8')) data = b'' def listen_proc(server): while True: socket, _ = server.accept() gevent.spawn(socket_proc, socket) print('start..') listen_proc(server)
One may use any tcp client, such as netcat, to send a short piece of data to the listening port, and will not receive any reply. Debugging shows that when the program calls the
select() for the 2nd time, it still return the socket object in
r, since there is no pending data in it, the next call to
socket.recv() blocks forever.
It seems this is a windows specific bug, as I've test it on linux and works without problem
I've done the following tests (all on widows, all python version are downloaded from python.org, gevent installed by pip)
So I guess this is something related to libuv
MacBook Air (M1, 2020) Darwin Kernel Version 21.4.0: arm64
Installing the latest version of
gevent on an M1 Mac requires building from source:
Building wheels for collected packages: gevent Building wheel for gevent (PEP 517) ... done Created wheel for gevent: filename=gevent-21.12.0-cp39-cp39-macosx_12_0_arm64.whl size=1732438 sha256=717895d5c98c05665286ab0284629d9f1642f947b710c1ad1b3e3115d589f470
This takes a long time which slows down project setup. Publishing a wheel for arm64 would greatly speed this up.
pip install gevent
I updated my system from Ubuntu 21.10 to 22.04 (and therefore from Python 3.9 to 3.10) and now our uwsgi application throws the following traceback very often:
The above exception was the direct cause of the following exception: Traceback (most recent call last): File "src/gevent/greenlet.py", line 906, in gevent._gevent_cgreenlet.Greenlet.run SystemError: <built-in function uwsgi_gevent_request> returned a result with an exception set 2022-05-05T09:31:14Z <Greenlet at 0x7f8a5a4a8a60: uwsgi_gevent_request(140232338205640)> failed with SystemError AttributeError: 'gevent.libev.corecext.io' object has no attribute 'active' The above exception was the direct cause of the following exception: Traceback (most recent call last): File "src/gevent/greenlet.py", line 831, in gevent._gevent_cgreenlet.Greenlet.join File "src/gevent/greenlet.py", line 857, in gevent._gevent_cgreenlet.Greenlet.join File "src/gevent/greenlet.py", line 846, in gevent._gevent_cgreenlet.Greenlet.join File "src/gevent/_greenlet_primitives.py", line 61, in gevent._gevent_c_greenlet_primitives.SwitchOutGreenletWithLoop.switch File "src/gevent/_greenlet_primitives.py", line 61, in gevent._gevent_c_greenlet_primitives.SwitchOutGreenletWithLoop.switch File "src/gevent/_greenlet_primitives.py", line 65, in gevent._gevent_c_greenlet_primitives.SwitchOutGreenletWithLoop.switch File "src/gevent/_gevent_c_greenlet_primitives.pxd", line 35, in gevent._gevent_c_greenlet_primitives._greenlet_switch File "src/gevent/greenlet.py", line 906, in gevent._gevent_cgreenlet.Greenlet.run SystemError: <built-in function uwsgi_gevent_request> returned a result with an exception set
I am not really sure if this is a gevent problem, but hopefully someone can give me hint where to look at.
If any information is missing to help, please let me know.
Best regards, Thomas
Recently, I wanted to get zerorpc running, that is based on greenlet and gevent. Importing zerorpc, leads to
/usr/lib/python3.7/importlib/_bootstrap.py:219: RuntimeWarning: greenlet.greenlet size changed, may indicate binary incompatibility. Expected 144 from C header, got 152 from PyObject return f(*args, **kwds) /usr/lib/python3.7/importlib/_bootstrap.py:219: RuntimeWarning: greenlet.greenlet size changed, may indicate binary incompatibility. Expected 144 from C header, got 152 from PyObject return f(*args, **kwds) /usr/lib/python3.7/importlib/_bootstrap.py:219: RuntimeWarning: greenlet.greenlet size changed, may indicate binary incompatibility. Expected 144 from C header, got 152 from PyObject return f(*args, **kwds) /usr/lib/python3.7/importlib/_bootstrap.py:219: RuntimeWarning: greenlet.greenlet size changed, may indicate binary incompatibility. Expected 144 from C header, got 152 from PyObject return f(*args, **kwds)
Only importing gevent, leads to these Warnings as well:
>>> import gevent /usr/lib/python3.7/importlib/_bootstrap.py:219: RuntimeWarning: greenlet.greenlet size changed, may indicate binary incompatibility. Expected 144 from C header, got 152 from PyObject return f(*args, **kwds) /usr/lib/python3.7/importlib/_bootstrap.py:219: RuntimeWarning: greenlet.greenlet size changed, may indicate binary incompatibility. Expected 144 from C header, got 152 from PyObject return f(*args, **kwds) /usr/lib/python3.7/importlib/_bootstrap.py:219: RuntimeWarning: greenlet.greenlet size changed, may indicate binary incompatibility. Expected 144 from C header, got 152 from PyObject return f(*args, **kwds) /usr/lib/python3.7/importlib/_bootstrap.py:219: RuntimeWarning: greenlet.greenlet size changed, may indicate binary incompatibility. Expected 144 from C header, got 152 from PyObject return f(*args, **kwds)
Gevent version is 21.12.0, greenlet version is 1.1.2. The python version is the one the Linux OS is shipped with. I am well aware that this issue is already fixed. However, the versions we use are way higher. Running this on on an Ubuntu 20.04, with x86_64 archictecture with (apparently) the same package versions, everything runs smoothly...
We also tried the following - yielding the same error:
Thanks for your help!
File "/home/<snip>/lib/python3.10/site-packages/gevent/selectors.py", line 208, in select for fd, event in iteritems(self._accumulated_events): TypeError: descriptor 'items' for 'dict' objects doesn't apply to a 'NoneType' object
The issue is as follows:
include_ready parameter to format_run_info() etc so that the dump can exclude greenlets that are ready. Also, changed the output from labeling such greenlets as
; finished to labeling them
; ready (finished) since the code's terminology for a finished greenlet is that it is "ready". Also, the dummy function
_ready() is renamed
_return_false() to better self-document its purpose.
sendallon a non-blocking socket could spuriously fail with a timeout.
sys.stderrhas been monkey-patched (not recommended), exceptions that the hub reports aren't lost and can still be caught. Reported in :issue:
825by Jelle Smet.
selectors.SelectSelectoris properly monkey-patched regardless of the order of imports. Reported in :issue:
835by Przemysław Węgrzyn.
reload(site)no longer fails with a
TypeErrorif gevent has been imported. Reported in :issue:
805by Jake Hilton.
waitto return prematurely. Reported in :issue:
771by Sergey Vasilyev.
refparameter to :func:
gevent.os.fork_and_watchwas being ignored.
gevent.queue.Channelis now correctly iterable, instead of raising a :exc:
socket.socket.recvmsg_intoon platforms where they are defined. Initial :pr:
773by Jakub Klama.
threading.RLocknow properly blocks (or deadlocks) in
acquireif the default value for timeout of -1 is used (which differs from gevent's default of None). The
acquiremethod also raises the same :exc:
ValueErrorexceptions that the standard library does for invalid parameters. Reported in #750 by Joy Zheng.
~gevent.event.Eventthat made it return
Falsewhen the event was set and cleared by the same greenlet before allowing a switch to already waiting greenlets. (Found by the 3.4 and 3.5 standard library test suites; the same as Python
bug 13502_. Note that the Python 2 standard library still has this race condition.)
~.AsyncResultnow wake waiting greenlets in the same (unspecified) order. Previously,
AsyncResulttended to use a FIFO order, but this was never guaranteed. Both classes also use less per-instance memory.
~logging.Loggeras a :mod:
pywsgierror or request log stream no longer produces extra newlines. Reported in #756 by ael-code.
~gevent.monkey.patch_allis called with
osset to False (not the default) but
signalis still True (the default). This combination of parameters will cause signal handlers for
SIGCHLDto not get called. In the future this might raise an error. Reported by Josh Zuech.
~gevent.monkey.patch_allis called more than once with different arguments. That causes the cumulative set of all True arguments to be patched, which may cause unexpected results.
threadingattributes from :func:
~socket.socket.sendallmethod of a gevent SSL socket that has a timeout now returns immediately (like the standard library does), instead of incorrectly raising :exc:
ssl.SSLEOFError. (Note that sending empty data with the :meth:
~socket.socket.sendmethod does raise
SSLEOFErrorin both gevent and the standard library.) Reported in #719 by Mustafa Atik and Tymur Maryokhin, with a reproducible test case provided by Timo Savola.
OverflowErrorwhen using the
readlinemethod of the WSGI input stream without a size hint or with a large size hint when the client is uploading a large amount of data. (This only impacted CPython 2; PyPy and Python 3 already handled this.) Reported in issue #289 by ggjjlldd, with contributions by Nathan Hoad.
SSLSocketnow raises the same ValueError the standard library does, instead of an
AttributeError. Found by updating gevent’s copy of the standard library test cases. Initially reported in issue #735 by Dmitrij D. Czarkoff.
gevent.lock.Semaphoresubclasses. If monkey-patched, this could also apply to :class:
threading.Semaphoreobjects. Reported in :issue:
660by Jay Oster.
details_). Thanks to Jay Oster.
~.WSGIHandlerto handle invalid HTTP client requests. Reported by not-bob.
~.WSGIServermore robustly supports :class:
~logging.Logger-like parameters for
error_log(as introduced in 1.1b1, this could cause integration issues with gunicorn). Reported in :issue:
663by Jay Oster.
~gevent.threading._DummyThreadobjects, created in a monkey-patched system when :func:
threading.current_threadis called in a new greenlet (which often happens implicitly, such as when logging) are much lighter weight. For example, they no longer allocate and then delete a :class:
~gevent.lock.Semaphore, which is especially important for PyPy.
gevent.pywsgiformats the status code correctly on Python 3. Reported in :issue:
664by Kevin Chen.
gevent.lock.Semaphore, which was unintentionally removed as part of making
Semaphoreatomic on PyPy on 1.1b1. Reported in :issue:
665by Hexchain Tong.
PYTHONOPTIMIZE. Previously these would go undetected if optimizations were enabled, potentially leading to erratic, difficult to debug behaviour.
peekwas called on an empty
Queue. Reported in #643 by michaelvol.
SIGCHLDhandlers specified to
signal.signalwork with the child watchers that are used by default. Also make
os.waitpidwork with a first argument of -1. Noted by users of gunicorn.
socket.makefile. Reported in #644 by Karan Lyons.
gevent.monkey.patch_builtinson Python 2 when the
future_ library is also installed. Reported by Carlos Sanchez.
ImportErrorif the CFFI module backing
gevent.coreneeds to be compiled when the hub is initialized (due to a missing or invalid
__pycache__directory). Now, the module will be automtically compiled when gevent is imported (this may produce compiler output on stdout). Reported in :issue:
619by Thinh Nguyen and :issue:
631by Andy Freeland, with contributions by Jay Oster and Matt Dupre.
gevent.socket.socket:sendallwith large inputs.
bench_sendall.py_ now performs about as well on PyPy as it does on CPython, an improvement of 10x (from ~60MB/s to ~630MB/s). See this
pypy bug_ for details.
gevent.socket.wait. Reported in #635 by lanstin.
gevent.socket.socket:sendtoproperly respects the socket's blocking status (meaning it can raise EWOULDBLOCK now in cases it wouldn't have before). Reported in :pr:
634by Mike Kaplinskiy.
threaded resolver <gevent.resolver_thread>are no longer always printed to stderr since they are usually out of the programmer's control and caught explicitly. (Programming errors like
TypeErrorare still printed.) Reported in :issue:
617by Jay Oster and Carlos Sanchez.
gevent.idle(). Reported in :issue:
imap_unorderedmethods of a pool support a
maxsizeparameter to limit the number of results buffered waiting for the consumer. Reported in :issue:
638by Sylvain Zimmer.
gevent.queue.Queuenow consistently orders multiple blocked waiting
getcallers in the order they arrived. Previously, due to an implementation quirk this was often roughly the case under CPython, but not under PyPy. Now they both behave the same.
gevent.queue.Queuenow supports the
gevent.monkey.patch_builtinscould cause PyPy to crash. Reported in #618 by Jay Oster.
gevent.killraises the correct exception in the target greenlet. Reported in #623 by Jonathan Kamens.
FileObjectPosix; this fixes e.g., help() on Python 3 when monkey-patched.
setup.pycan be run from a directory containing spaces. Reported in :issue:
319by Ivan Smirnov.
setup.pycan build with newer versions of clang on OS X. They enforce the distinction between CFLAGS and CPPFLAGS.
gevent.lock.Semaphoreis atomic on PyPy, just like it is on CPython. This comes at a small performance cost.
successfulvalue to False when killing a greenlet before it ran with a non-default exception. Fixed in :pr:
608by Heungsub Lee.
os.waitpidto become unreliable due to the use of signals on POSIX platforms. This was especially noticeable when using
gevent.subprocessin combination with
multiprocessing. Now, the monkey-patched
osmodule provides a
waitpidfunction that seeks to ameliorate this. Reported in :issue:
600by champax and :issue:
452by Łukasz Kawczyński.
select.poll, provide a gevent-friendly
gevent.select.polland corresponding monkey-patch. Implemented in :pr:
604by Eddi Linder.
531by M. Nunberg and implemented in :pr:
gevent.thread.allocate_lock(and so a monkey-patched standard library
allocate_lock) more closely matches the behaviour of the builtin: an unlocked lock cannot be released, and attempting to do so throws the correct exception (
thread.erroron Python 2,
RuntimeErroron Python 3). Previously, over-releasing a lock was silently ignored. Reported in :issue:
308by Jędrzej Nowak.
gevent.fileobject.FileObjectThreaduses the threadpool to close the underling file-like object. Reported in :issue:
gevent.pywsgihandler is handled more robustly, resulting in "HTTP 400 bad request" responses instead of a 500 error or, in the worst case, a server-side hang. Reported in :issue:
229by Björn Lindqvist.
threadingmodule before using
gevent.monkey.patch_all()no longer causes Python 3.4 to fail to get the
reprof the main thread, and other CPython platforms to return an unjoinable DummyThread. (Note that this is not recommended.) Reported in :issue:
iopackage to implement
FileObjectPosix. This unifies the code with the Python 3 implementation, and fixes problems with using
seek(). See :issue:
108by shaun and initial fix based on code by Sylvain Zimmer.
spawn_later, as well as the
Greenletconstructor, immediately produce useful
TypeErrors if asked to run something that cannot be run. Previously, the spawned greenlet would die with an uncaught
TypeErrorthe first time it was switched to. Reported in :issue:
gevent.threadpool.ThreadPool.applyno longer raises a
geton the result still could; you must be careful to use the correct hub). Reported in :issue:
threadingmodule is monkey-patched, the module-level lock in the
loggingmodule is made greenlet-aware, as are the instance locks of any configured handlers. This makes it safer to import modules that use the standard pattern of creating a module-level
Loggerinstance before monkey-patching. Configuring
loggingwith a basic configuration and then monkey-patching is also safer (but not configurations that involve such things as the
threading.RLockunder Python 3.
importlib. Reported in :issue:
615by Daniel Mizyrycki. (The same thing could happen under Python 2 if a
threading.RLockwas held around the monkey-patching call; this is less likely but not impossible with import hooks.)
381and fixed in :pr:
616by Chris Lane.
logging.Loggerinstance for its
error_logparameters. Take care that the system is fully monkey-patched very early in the process's lifetime if attempting this, and note that non-file handlers have not been tested. Fixes :issue:
imap_unorderednow accept multiple iterables.
Groupmapping/application functions should now have the original traceback.
gevent.threadpool.ThreadPool.applynow raises any exception raised by the called function, the same as
Pooland the builtin
applyfunction. This obsoletes the undocumented
apply_efunction. Original PR #556 by Robert Estelle.
patch_selecton Python 3.4. See #591 .
gevent.monkeymodule allow knowing what was patched. Discussed in :issue:
135and implemented in :pr:
325by Nathan Hoad.
597by David Ford.
gevent.socket.socket.sendallsupports arbitrary objects that implement the buffer protocol (such as ctypes structures), just like native sockets. Reported in :issue:
onerrorattribute present in CFFI 1.2.0 for better signal handling under PyPy. Thanks to Armin Rigo and Omer Katz. (See https://bitbucket.org/cffi/cffi/issue/152/handling-errors-from-signal-handlers-in)
gevent.subprocessmodule is closer in behaviour to the standard library under Python 3, at least on POSIX. The
start_new_sessionarguments are now unimplemented, as are the
timeoutparameters to various functions. Under Python 2, the previously undocumented
Popen.communicateraises an exception like its Python 3 counterpart.
gevent.subprocessmodule no longer leaks file descriptors. Reported in :pr:
echoserver.pyno longer binds to the standard X11 TCP port. Reported in :issue:
gevent.iwaitno longer throws
LoopExitif the caller switches greenlets between return values. Reported and initial patch in :pr:
467by Alexey Borzenkov.
multiprocessing.Process. Previously the child process would hang indefinitely. Reported in :issue:
230by Lx Yu.
gevent.killallaccepts an arbitrary iterable for the greenlets to kill. Reported in :issue:
404by Martin Bachwerk; seen in combination with older versions of simple-requests.
gevent.local.localobjects are now eligible for garbage collection as soon as the greenlet finishes running, matching the behaviour of the built-in
threading.local(when implemented natively). Reported in :issue:
gevent.greenlet.Greenlet.kill) before it is actually started and switched to now prevents the greenlet from ever running, instead of raising an exception when it is later switched to. See :issue:
330reported by Jonathan Kamens.