>> Here the code is wrong, uwsgi.async_sleep only inform the schedueler to
>> wait for 5 seconds after the first suspension so it should be written as
>>
>> def application(e, s):
>> s('200 OK', [('Content-Type', 'text/html')])
>> yield uwsgi.async_sleep(5)
>> yield 'Hello world'
>
> Ah thank you, the AsyncSupport wiki page talked about it in the same
> context as time.sleep() so I thought the behavior would be the same and
> would suspend immediately. Is there any proper explanation of the uwsgi
> module? Aside from uwsgi-*/uwsgi_API.txt, and various snippets on the wiki
> which aren't too explanatory, I can't find any proper documentation.
There is still no complete documentation about uWSGI api, mostly because
it is starting to stabilize only now. But async/non-blocking programming
is composed by only few functions:
uwsgi.wait_fd_read(fd[, timeout])
uwsgi.wait_fd_write(fd[, timeout])
uwsgi.async_connect(address[, timeout])
uwsgi.close(fd)
uwsgi.suspend()
uwsgi.async_sleep()
this should be now stable (used even in PSGI plugin) and i would use them
in a production app without problems.
>
> I feel silly now I should've realized this. Thank you. One final question
> if that's alright as I don't want to start another thread, when using the
> built in uwsgi server sending responses in chunks are returned to the
> browser and displayed piece by piece. With nginx it seems to be buffered.
> I thought perhaps this was due to the uwsgi module and the uwsgi_buffer*
> options but there's no way to disable them (errors about minimums). Is
> there something I can do about this in the uwsgi module or is this just
> straight nginx related behaviour?
it's nginx related, but afaik you should be able to set the nginx
buffering to lower values.
--
Roberto De Ioris
http://unbit.it
_______________________________________________
uWSGI mailing list
[email protected]
http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
