On Tue, Feb 18, 2014 at 11:48:19AM -0700, Don Brown wrote: > Great work chrysn. Does the same limitation apply that you can't use Task > manually any more? I use them a lot in a sql driver library I'm working > on, and can see using them in other places as well.
it does; you'd have to add a register_subtask(the_new_task) function, which stores the new task's id in a dictionary that get_ident conults to tell werkzeug that we're in the original task. > As for the patch, give me your github account and I'll give you commit > access. my github user is chrysn. > [...] though you do have to be careful for things like SQLAlchemy that > will block for everything. i've read contradictory statements on whether sqlalchemy will have an asyncio interface or not. for the time being, some of that might have to be run in an executor (or on a server that has multiple threads, and is ok with some blocking). > It does make me wonder if we wouldn't be better off just forking or > creating a new web framework to make it more clear you do need async > versions of everything, kinda like Node has effectively done by using > server-side Javascript. the web frameworks should be portable enough (as you have demonstrated with flask and bottle), and i don't think we want to start rewriting sqlalchemy from scratch. call me smug, but i confide the python community can cope with this without reinventing everything. > I did this by the usual sprinkling of yield from around, but also > rewrote all uses of thread-local variables to be explicit. i agree that it's not pythonic, but at least for werkzeug, it was confirmed in the pocoo asyncio thread that it's a design decision -- and a popular one, it seems. other web frameworks might behave better (afair django is explicit except when it comes to translations), but all together flask seems nice enough to me to pursue getting it fully running on asyncio. an issue i have not solved to my satisfaction is sending early headers. in flask, unless i resort to writing a full wsgi application (which i currently do), heades are sent when a Response object is returned. that works well for things like get-request/asyncio-something/return-data workflows, but not for get-request/return-heades/wait/send-data/... workflows as they'd seen in longpolling, server-sent events, animated-gif streaming etc. moreover, this should integrate somehow with pep3333, which uses yield as a means of flow control. do you already have a solution for that at hand? best regards chrysn -- To use raw power is to make yourself infinitely vulnerable to greater powers. -- Bene Gesserit axiom
signature.asc
Description: Digital signature
