monkey patch breaks gevent.sleep(0)

[tshuval]

After monkey patching (specifically socket), gevent.sleep(0) does not yield and the spawned greenlet is not executed.
When setting the time of the sleep() to a positive number, the greenlet will start running.

Reproduce:

from gevent import monkey; monkey.patch_socket()
import gevent
import socket

def f():
    s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
    s.connect(('', 8888))
    s.sendall('beep')

gevent.spawn(f)
gevent.sleep(0)    # ... BUG! nothing happens.... but:
gevent.sleep(0.1)  # ... and the greenlet will start running

As far as I understand, sleep(0) should behave the same as sleep(<positive number>)

Environment:
Python 2.7.6
gevent 1.0.2
greenlet 0.4.9

[jamadden]

sleep(0) is not the same thing as sleeping for a specific amount of time. See the documentation for an explanation, but basically this code is working as expected.

[tshuval]

OK, so I basically need to sleep to something like 0.001 seconds instead of 0.
Thanks for the clarification.

[jamadden]

I'm assuming that the example is very simplified from your real use-case. So yes, in that simplified example, simply sleep with a positive number. In a real program with many greenlets, sleep() or sleep(0) is usually most efficient at yielding to other greenlets because it doesn't involve a trip around the event loop.

[tshuval]

You are correct. My use case is a pool of greenlets getting items from a queue and sending them to a remote server.
However, using sleep(0) still creates the bug. My pseudo code is like this:

greenlet:
    while True:
        read 100 items from queue
        pack the items and send to remote server
        gevent.sleep(0)

main loop:
    spawn 10 greenlets
    while True:
        print 'beep'
        gevent.sleep(0.001)

I'm using the requests package.
Doing so, I can see in the log that a connection is created (requests.packages.urllib3.connectionpool:Starting new HTTP connection (1)) BUT the remote server DOES NOT receive any request until all greenlets have created a connection.
Another thing, if I change the value of the sleep of the main loop to 0 (instead of 0.001), then I can see something like 3 connections established, then about 50 'beep' messages, then 3 more connections, then 50 more 'beeps'.
This seems like a strange behavior.

[jamadden]

Every time you sleep with a positive number, you're saying "don't run this greenlet again until the next iteration of the event loop where the time has elapsed".

At the top of the event loop, timeouts like this are checked and run, and then the operating system select call is processed to see if any I/O is ready to be processed. Last, greenlets that got scheduled during the previous steps, but have not yet run, are run---and they can schedule other greenlets for any of those phases, including to be run after themselves but (potentially) before the next loop iteration: that's what sleep(0) does.

Not all socket operations are going to be ready at the exact same instance, and even if they are, depending on the select implementation, it may take a few iterations to have them reported as ready.

Those are all implementation details, of course, and subject to change. My point is only that, while in principle all gevent operations are ordered, once you start mixing I/O and CPU bound operations (such as reading/writing a gevent queue, or sleep(0) vs sleep(1)), it becomes more difficult to reason about exactly what the order will be. In that way it's not much different than preemtible threads.

BTW, in this example, I probably wouldn't be sleep(0) in a while True loop (your greenlet). You're going to get better resource utilization if you let the natural blocking occur, either when you pull from a queue or try to spawn a new greenlet. Why? sleep(0) is going to unconditionally wake up this greenlet, even if there's nothing to do, whereas the blocking operations specifically schedule the greenlet only to wake up when there's something to do. Pretty much the same thing goes for the main loop. You can use Event objects or Semaphores or AsyncResult objects to schedule communication between greenlets when no natural blocking exists (pulling from a queue, joining/waiting on greenlets/pools, etc.)

[tshuval]

@jamadden Thanks a lot for the helpful insights!

[jamadden]

Cool. Can you close this then?