gevent working with latest uWSGI

[Roberto De Ioris]

Hi all, i am pleased to announce that with the latest greenlet plugin

http://projects.unbit.it/uwsgi/wiki/AsyncSupport#SuspendResume

uWSGI in async mode can take advantage of the gevent api (and monkey
patching system).

The two system works gracefully and uWSGI take in account even the gevent
switches between greenlet. The only rule for a safe app is not mixing the
uwsgi async api for fd monitoring with the gevent one. All the other
functions of the api (included uwsgi.suspend()) can be used without
problems.

I will make a dedicated doc page in the uWSGI wiki ASAP

I hope this can be useful.

--
Roberto De Ioris
http://unbit.it

[Denis Bilenko]

Hi Roberto,

Great news!

Could you explain a bit how it works? Also where's the code that implements it?
I only found this:
http://projects.unbit.it/uwsgi/browser/plugins/greenlet/greenlet.c
but from brief look it does not seem to be enough for proper gevent support.

Is there some other file I'm missing?

Cheers,
Denis.

[Roberto De Ioris]

> Hi Roberto,
>
> Great news!
>
> Could you explain a bit how it works? Also where's the code that
> implements it?
> I only found this:
> http://projects.unbit.it/uwsgi/browser/plugins/greenlet/greenlet.c
> but from brief look it does not seem to be enough for proper gevent
> support.
>
> Is there some other file I'm missing?

uWSGI use hooks for all of its internal functions.

The plugin you are seeing only "patch" the suspend/resume system
integrated in uWSGI with the greenlet one. (effectively mapping a uwsgi
async core to a greenlet)

The code of the eventloop is here

http://projects.unbit.it/uwsgi/browser/async.c

But again, most of the relevant (in the python side) part are under the
python plugin in plugins/python directory.

The "hack" that allows integration is in the event_queue_wait_multi().
This function will not block until there are greenlet/requests available,
so the scheduler will give control to gevent hub or the other greenlet
spawned during requests.

If you use the uwsgi api to wait for file descriptor you will destroy this
ecosystem as event_queue_wait_multi() could block and the gevent hub will
not get in the runqueue. (But i do not see reason to use the uwsgi async
api
mixed with the gevent one, so it should be not a problem)

There is a special case when a user call gevent.spawn() in a WSGI callable
but it returns leaving the spawned greenlet running itself without a
request associated to it:

def application(e, sr):
sr(.....)
gevent.spawn(......)
return "Hello World"

If there are no requests pending, event_queue_wait_multi() could block in
this specific case. This will be easy to fix, but it obviously need more
tests.