I've managed to work around the cooperative read problem, by patching
Django's read() from wsgi.input and calling
gevent.socket.wait_read(environ['wsgi.input'].fileno()) before the
actual read() call. This way, when there is no data to read, the flow
will be switched to another greenlet. It seems to work.
But I've still got the cooperative write problem. Since my application
returns an iterator to uWSGI, it seems that it's uWSGI that's writing
to the client socket and not cooperating. Is there an wsgi.output
environment variable that I can use to wait on, until I'm able to
write? Or maybe I can reuse wsgi.input, it should be the same socket.
On another note, can't uWSGI's gevent loop engine handle these
scenarios and switch greenlets when a read() does not have anything to
read and a write() would block?
Best regards,
André
Citando André Cruz <[email protected]>:
Hello.
I have a Django application that does uploads and downloads of
files. Since these are slow requests, I don't want a thread or a
process per request, so I was thinking of using greenlets.
I have setup a uWSGI server with the Gevent loop, and I can do long
polling requests just fine. I wait for a Gevent.Event and the thread
switches to another greenlet which handles other requests meanwhile.
The problem is that it seems read()s from the Django request object
are not cooperative, as also response writes. Is there anyway to
make these cooperative as well?
Thanks,
André Cruz
_______________________________________________
uWSGI mailing list
[email protected]
http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
_______________________________________________
uWSGI mailing list
[email protected]
http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
