On Fri, Feb 21, 2014 at 7:01 AM, chrysn <chr...@fsfe.org> wrote: > On Tue, Feb 18, 2014 at 11:48:19AM -0700, Don Brown wrote: > <snip /> > > 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. >
I wonder how that would affect third-party libraries. I guess it should only affect those that either use request or call functions that use request, but still I worry it'd be a source of obscure bugs. > > As for the patch, give me your github account and I'll give you commit > > access. > > my github user is chrysn. > Added. > > > [...] 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). > > Yeah, that's the approach the twisted adbapi lib takes (create a bunch of threads), which is about the only thing you can do really. > > 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. > Well, even with those, I had to make an incompatible fork that won't be accepted for a long time, as they want to preserve 2.x compatibility. I agree writing things from scratch is rather perilous as I'm confirming with my experiences with the redis and mongo libraries :) > <snip /> > > 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. > Oh, and there is the issue about reading the request body. aiohttp supports reading as a coroutine where flask and others assume it is a blocking stream. How aiohttp supports that is by reading the whole body into a byte stream then returning that. While that is fine for most web apps, it isn't ideal. > > 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? > Nope, haven't looked at that yet. I've been running these with a gunicorn + aiohttp (note you have to fix the aiohttp worker to read the request body fully first). Don > > best regards > chrysn > > -- > To use raw power is to make yourself infinitely vulnerable to greater > powers. > -- Bene Gesserit axiom >
