Would be cool to have python3 support, ideally as single source.

Here's an old python3 fork: http://bitbucket.org/jjonte/gevent

Reported by Denis.Bilenko.

earlier comments

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.

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 greenlet and stackless), easily on par in its potential with the success of Node.js.

• On Python 3.11a6 and newer, get the PyFrameObject structure from the internal C API ("internal/pycore_frame.h").

• On Python 3.9 and newer, use PyFrame_GetBack() and PyFrame_GetCode().

• Add frame getter and setter functions to greenlet:

  • get_f_code(frame)
  • set_f_lineno(frame, lineno)
  • set_f_code(frame, code)

• greenlet.h: the CFrame type has been renamed to _PyCFrame.

Greenlets in 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()

...2 x CLEANUP BAR + 1 x CLEANUP FOO gets printed when Ctrl-C is pressed during that time.sleep(1.0) call.

However, when using gevent (unless 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)])

...neither 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 gevent.

(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:

https://docs.python.org/3/library/ctypes.html#callback-functions

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, ('41.234.232.59', 40471))> failed with SSLError

is there any solution?

In v2.7.8-12 of the Debian python suit, which was released 3 days ago, they added a patch, which, according to the changelog, "Allow building and testing without SSLv3 support"

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.

Referencing this here since the stack trace originates in gevent.

#6  0x0000000000549867 in _PyTrash_thread_destroy_chain () at Objects/object.c:2276
#7  0x000000000054992b in _PyTrash_end (tstate=0x9f7e18 <_PyRuntime+166328>) at Objects/object.c:2301
#8  0x000000000055c1eb in tupledealloc (op=0x7ff686941c20) at Objects/tupleobject.c:215
#9  0x0000000000549ba2 in _Py_Dealloc (
    op=((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((0x0, None), 83), None), 55), None), 13), None), 42), None), 70), None), 7), None), 8), None), 51), None), None), ()), (...)), (...)), None), None), 15), None), 64), None), 94), None), 76), None), None), None), None), None), None), 91), None), 41), None), None), None), None), 31), None), 4), None), None), None), 78), None), 79), None), None), None), None), None), 92), None), 39), None), 23), None), 93), None), 68), None), 47), None), 74), None), 84), None), 72), None), 98), None), 61), None), 90), None), None), 99), 33)) at Objects/object.c:2389
#10 0x00007ff6877dbd1d in Py_DECREF (op=<optimized out>) at /home/arcivanov/.pyenv/versions/3.11.0rc2/include/python3.11/object.h:538
#11 __pyx_f_6gevent_17_gevent_cgreenlet_8Greenlet__Greenlet__free (__pyx_v_self=__pyx_v_self@entry=0x7ff686929310) at src/gevent/greenlet.c:14915
#12 0x00007ff6877f0cbf in __pyx_pf_6gevent_17_gevent_cgreenlet_8Greenlet_42run (__pyx_v_self=0x7ff686929310) at src/gevent/greenlet.c:14741
#13 __pyx_pw_6gevent_17_gevent_cgreenlet_8Greenlet_43run (__pyx_v_self=<gevent._gevent_cgreenlet.Greenlet at remote 0x7ff686929310>, unused=<optimized out>) at src/gevent/greenlet.c:14521

https://github.com/python/cpython/issues/98110

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?

• gevent version: 21.1.2 installed through pip 21.0
• Python version: Python 3.9.1 built from source from python.org through Macports 2.6.4
• Operating System: MacOS 10.11.6

Description:

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 !

• gevent version: 22.10.2 via pip install
• Python version:

Python 3.9.9 (main, Nov 18 2021, 07:23:37) [Clang 13.0.0 (clang-1300.0.29.3)] on darwin

• Operating System:

ProductName: macOS ProductVersion: 12.6 BuildVersion: 21G115

Description:

I expected gevent to perform comparably to asyncio on Python 3.9 and that gevent not have a performance regression on Python 3.11.

All details and reproduction notes are here:

https://dev.to/skywind3000/performance-asyncio-vs-gevent-vs-native-epoll-bnl

What I've run:

I replicated these results on the system described at the top of the issue on Python 3.9 (primarily to see if asyncio really is that much faster). I have not replicated the performance regression on Python 3.11 but trust the results on that benchmark page after replicating the situation on Python 3.9.

All details for reproduction are here:

https://dev.to/skywind3000/performance-asyncio-vs-gevent-vs-native-epoll-bnl

Bottom line - has gevent fallen behind asyncio in performance and will it / can it catch up?

Environment:

Python 2.7.18 grpcio ==1.30.0 grpcio-tools==1.30.0

ERROR:

Fatal Python error: Segmentation fault Thread 0x0000fffe178bf1e0 <grpc_global_tim> (most recent call first): File "py2/lib64/python2.7/site-packages/gevent-1.2.2-py2.7-linux-aarch64.egg/gevent/_threading.py", line 152 in wait File "/py2/lib64/python2.7/site-packages/gevent-1.2.2-py2.7-linux-aarch64.egg/gevent/_threading.py", line 436 in get File "/py2/lib64/python2.7/site-packages/gevent-1.2.2-py2.7-linux-aarch64.egg/gevent/threadpool.py", line 200 in _worker Thread 0x0000fffe1eb95880 <grpc_global_tim> (most recent call first): File "/py2/lib64/python2.7/site-packages/gevent-1.2.2-py2.7-linux-aarch64.egg/gevent/hub.py", line 691 in run

Gdb Test:

Program terminated with signal SIGSEGV, Segmentation fault. #0 0x0000fffbc8043470 in raise () from /usr/lib64/libpthread.so.0 [Current thread is 1 (LWP 1066998)] (gdb) bt #0 0x0000fffbc8043470 in raise () from /usr/lib64/libpthread.so.0 #1 #2 grpc_closure_list_append (error=0x0, closure=0x6c756f6320534c54, closure_list=0xfffbb3ffe918) at ./src/core/lib/iomgr/closure.h:183 #3 exec_ctx_sched (error=0x0, closure=0x6c756f6320534c54) at src/core/lib/iomgr/exec_ctx.cc:50 #4 grpc_core::ExecCtx::Run (location=..., closure=0x6c756f6320534c54, error=0x0) at src/core/lib/iomgr/exec_ctx.cc:195 #5 0x0000fffbc5e043ac in grpc_core::LockfreeEvent::SetReady (this=this@entry=0xaaae40612ef8) at src/core/lib/iomgr/lockfree_event.cc:243 #6 0x0000fffbc5df89ec in fd_become_writable (fd=0xaaae40612e60) at src/core/lib/iomgr/ev_epollex_linux.cc:818 #7 pollable_process_events (pollset=pollset@entry=0xaaae3f983c30, pollable_obj=pollable_obj@entry=0xaaae3c8f3d40, drain=drain@entry=false) at src/core/lib/iomgr/ev_epollex_linux.cc:917 #8 0x0000fffbc5df9cb8 in pollset_work (pollset=0xaaae3f983c30, worker_hdl=, deadline=) at src/core/lib/iomgr/ev_epollex_linux.cc:1139 #9 0x0000fffbc5cf9fdc in run_poller (arg=0xaaae3c840470, error=) at src/core/ext/filters/client_channel/backup_poller.cc:130 #10 0x0000fffbc5dffca0 in exec_ctx_run (closure=, closure=, error=0x0) at src/core/lib/iomgr/exec_ctx.cc:40 #11 grpc_core::ExecCtx::Flush (this=0xfffbb3ffe910) at src/core/lib/iomgr/exec_ctx.cc:153 #12 0x0000fffbc5e17b58 in run_some_timers () at src/core/lib/iomgr/timer_manager.cc:134 #13 timer_main_loop () at src/core/lib/iomgr/timer_manager.cc:237 #14 timer_thread (completed_thread_ptr=0x4) at src/core/lib/iomgr/timer_manager.cc:284 #15 0x0000fffbc5dec990 in grpc_core::(anonymous namespace)::ThreadInternalsPosix::<lambda(void*)>::operator() (__closure=0x0, v=) at src/core/lib/gprpp/thd_posix.cc:140 #16 grpc_core::(anonymous namespace)::ThreadInternalsPosix::<lambda(void*)>::_FUN(void *) () at src/core/lib/gprpp/thd_posix.cc:145 #17 0x0000fffbc80387ac in ?? () from /usr/lib64/libpthread.so.0 #18 0x0000fffbc7de5cec in ?? () from /usr/lib64/libc.so.6

• gevent version: "~21.12.0" pypi
• Python version: python:3.9 from slim-buster docker image
• Operating System: python:3.9-slim-buster docker image

Description:

Running django 3.2 using gunicorn 20.1. I keep seeing this traceback in my logs from gevent/_abstract_linkable.py assert self._notifier is notifier, (self._notifier, notifier).

Traceback (most recent call last):
File "src/gevent/_abstract_linkable.py", line 287, in gevent._gevent_c_abstract_linkable.AbstractLinkable._notify_links
File "src/gevent/_abstract_linkable.py", line 333, in gevent._gevent_c_abstract_linkable.AbstractLinkable._notify_links
AssertionError: (None, <callback at 0x7f3af9646600 args=([],)>)

No other logs surrounding these in the given context.

Is this something to be concerned about or anything I can fix?

What I've run:

ddtrace-run gunicorn --workers 5 --worker-class gevent project_name.wsgi:application

• gevent version: master
• Python version: 3.8+
• Operating System: Linux 4.x, 5.x

Description:

Hello, Thanks for making Gevent living up and active development.

Given that the gevent-websocket (https://pypi.org/project/gevent-websocket/) project has been long inactive - presumably dead - and has many bugs, I wonder if - from the software architecture point of view - gevent project has any interest to step up and implement the websocket support within gevent.

Not wanting to make any kind of comparision, but the only reason we have to stay with eventlet is its native websocket support while performance is low. Gevent delivers much better performance using libev + Cython, and under active development + maintenance. It would be great deal to have websocket support within gevent.

Many thanks.

• gevent version: 21.12.0 from PyPi.
• Python version: 3.9.9 using pyenv
• Operating System: ArchLinux

Description:

Given this piece of code:

from gevent import monkey, config, Timeout, sleep
config.loop = 'libev-cext'  # No timeout with 'libuv'
monkey.patch_all()

def main():
    with Timeout(seconds=0.5) as timeout:
        for i in range(10):
            sleep(0.1)
            timeout.cancel()
            timeout.start()

    print("Safe")


if __name__ == "__main__":
    main()

I'd expect it to execute until the end and print Safe. However, the timeout triggers and it fails with Timeout exception:

Traceback (most recent call last):
  File "/home/bullno1/Projects/gevent-bug/timeout.py", line 16, in <module>
    main()
  File "/home/bullno1/Projects/gevent-bug/timeout.py", line 8, in main
    sleep(0.1)
  File "/home/bullno1/.cache/pypoetry/virtualenvs/gevent-bug-8hnsNxAf-py3.9/lib/python3.9/site-packages/gevent/hub.py", line 166, in sleep
    hub.wait(t)
  File "src/gevent/_hub_primitives.py", line 46, in gevent._gevent_c_hub_primitives.WaitOperationsGreenlet.wait
  File "src/gevent/_hub_primitives.py", line 55, in gevent._gevent_c_hub_primitives.WaitOperationsGreenlet.wait
  File "src/gevent/_waiter.py", line 154, in gevent._gevent_c_waiter.Waiter.get
  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
gevent.timeout.Timeout: 0.5 seconds

This seems to be unique to the libev loop as changing the event loop to libuv will let the code run until completion.

• gevent version: 21.12 from pip
• Python version: cPython 3.7.6 downloaded from python.org
• Operating System: windows 7 x64

Description:

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.

test code:

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)

• python 2.7.11+ gevent 1.2.2: works
• python 2.7.11+ gevent 1.3.0: buggy
• python 2.7.11+ gevent 1.4.0: buggy
• python 2.7.11+ gevent 1.5.0: buggy
• python 2.7.11+ gevent 21.12: buggy
• python 3.7.6+ gevent 21.12: buggy

So I guess this is something related to libuv