eventlet VS gevent

index 714cb3a6..47c5c039 100644 --- a/tools/pip-requires +++ b/tools/pip-requires @@ -2,7 +2,7 @@ # NOTE: OpenStack avoids some versions of eventlet, because of the # following issue. # https://github.com/eventlet/eventlet/issues/401 -eventlet==0.31.1 +eventlet==0.33.3 msgpack>=0.4.0 # RPC library, BGP speaker(net_cntl) netaddr oslo.config>=2.5.0

root@agrover-OptiPlex-780:~# easy\_install -U eventlet Searching for eventlet Reading http://pypi.python.org/simple/eventlet/ Reading http://wiki.secondlife.com/wiki/Eventlet Reading http://eventlet.net Best match: eventlet 0.9.16 Processing eventlet-0.9.16-py2.7.egg eventlet 0.9.16 is already the active version in easy-install.pth Using /usr/local/lib/python2.7/dist-packages/eventlet-0.9.16-py2.7.egg Processing dependencies for eventlet Searching for greenlet>=0.3Reading http://pypi.python.org/simple/greenlet/Reading https://github.com/python-greenlet/greenletReading http://bitbucket.org/ambroff/greenletBest match: greenlet 0.3.4Downloading http://pypi.python.org/packages/source/g/greenlet/greenlet- 0.3.4.zip#md5=530a69acebbb0d66eb5abd83523d8272Processing greenlet-0.3.4.zipWriting /tmp/easy_install-_aeHYm/greenlet-0.3.4/setup.cfgRunning greenlet-0.3.4/setup.py -q bdist_egg --dist-dir /tmp/easy_install-_aeHYm/greenlet-0.3.4/egg-dist-tmp-t9_gbWIn file included from greenlet.c:5:0:greenlet.h:8:20: fatal error: Python.h: No such file or directorycompilation terminated.error: Setup script exited with error: command 'gcc' failed with exit status 1` Why can't Python.h be found?

i would see if http://www.gevent.org/ or http://eventlet.net/ works on windows first

Nameko is built on top of the eventlet library, which provides concurrency via “greenthreads”.

A sub-question for the folks here: is anyone using the combination of gevent and PyPy for a production application? Or, more generally, other libraries that do deep monkey-patching across the Python standard library?

Things like https://github.com/gevent/gevent/issues/676 and the fix at https://github.com/gevent/gevent/commit/f466ec51ea74755c5bee... indicate to me that there are subtleties on how PyPy's memory management interacts with low-level tweaks like gevent that have relied on often-implicit historical assumptions about memory management timing.

Not sure if this is limited to gevent, either - other libraries like Sentry, NewRelic, and OpenTelemetry also have low-level monkey-patched hooks, and it's unclear whether they're low-level enough that they might run into similar issues.

For a stack without any monkey-patching I'd be overjoyed to use PyPy - but between gevent and these monitoring tools, practically every project needs at least some monkey-patching, and I think that there's a lack of clarity on how battle-tested PyPy is with tools like these.

I'm not sure how much it replicates the CSP model, but the closest thing I've found to Go-style concurrency in Python is gevent: https://github.com/gevent/gevent

I personally still prefer to use it in all my projects.

Greenlet seems to have some troubles compiling with Python 3.9. https://github.com/gevent/gevent/issues/1627