Allow prepare to be async #605

wants to merge 4 commits into


None yet

3 participants

acasajus commented Oct 4, 2012

Allow prepare to be async like the normal get/post/... methods using the asynchronous decorator and having to call end_prepare.

ei-grad commented Oct 4, 2012

I think it would be good to mention this feature in docstring of asynchronous decorator.

ps. there was many requests for this, I also faced with need of asynchronous prepare to get a redis db connection from pool (or establish it if there are no free connections)... now i have to add r = redis.get_locked_connection() in the beginning of every handlers get/post methods... (of course, it could be implemented in custom BaseHandler, but it looks bad to change API semantics in the application this way)

acasajus commented Oct 5, 2012

Done :)

bdarnell commented Oct 6, 2012

Needs a test case. Tests should cover asynchronous prepare with both sync and async main methods, and also cover the case where the request is finished in prepare.

Maybe call the end method finish_prepare for consistency with finish? If I were starting from scratch I'd say that the @asynchronous decorator would call the decorated method with an extra callback argument, but I guess it's not worth making the behavior of prepare and get/post/etc different.

acasajus commented Oct 9, 2012

Added the test case.

I was just trying to mimic the @asynchronous behavior for prepare. I don't think it's worth having two different ways of treating async stuff.


Is there more input wrt this or will it be merged?

bdarnell commented May 1, 2013

Sorry to leave this in the queue for so long. My thinking on asynchronous methods has evolved with the use of coroutines and Futures in 3.0. We can say now that a method is asynchronous if it returns a Future, and this means we don't have to give each potentially-asynchronous method its own finish method. The @asynchronous decorator already detects if its target returns a Future and runs finish() automatically (this is not just a convenience, but turns out to be necessary for error handling). I'd like to do something similar for prepare(), and potentially other methods.

@bdarnell bdarnell added a commit that closed this pull request May 12, 2013
@bdarnell bdarnell Allow prepare to be asynchronous, and detect coroutines by their result.
The prepare method does not use the @asynchronous decorator, only
@gen.coroutine (or @return_future; it detects the Future return type).
The same logic is now available for the regular http verb methods as well.

Closes #605.
@bdarnell bdarnell closed this in ca8495d May 12, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment