This is a false problem. Flask and web2py are not asynchronous like Tornado. This is not a problem nor a limitation but a difference in design that determine the way one program web applications. Scalability and speed have to do with database bottleneck more than everything else.
About the comment "Flask uses thread local objects internally ... it also does not scale well to large applications" I do not have much to say. I do not see why that should be a problem but you should ask the author. Web2py only use something similar to thread local variables to keep track of open databases and keep a connection pool in a thread-safe manner. This is for scalability, not against it. Massimo On Jun 10, 10:54 pm, Anthony <av201...@yahoo.com> wrote: > From the Flask documentation: > > "For example Flask uses thread local objects internally so that you > don’t have to pass objects around from function to function within a > request in order to stay threadsafe. While this is a really easy > approach and saves you a lot of time, it also does not scale well to > large applications." (http://flask.pocoo.org/docs/foreword/#what-does- > micro-mean) > > and > > "Yes it is usually not such a bright idea to use thread locals. They > cause troubles for servers that are not based on the concept of > threads and make large applications harder to maintain. However Flask > is just not designed for large applications or asynchronous > servers." (http://flask.pocoo.org/docs/design/#thread-locals) > > Admittedly, I don't understand the technical issues here, but are the > scalability issues associated with Flask's thread locals approach also > a problem for web2py? Just curious. > > On Jun 10, 10:03 pm, mdipierro <mdipie...@cs.depaul.edu> wrote: > > > Flask has a clever mechanism that web2py also uses internally in DAL. > > It partially addresses the problem: > > > Consider this example: > > >http://github.com/mitsuhiko/flask/blob/master/examples/flaskr/flaskr.py > > > Consider the action "login". request is a global object that acts as a > > proxy. Any attribute of request gets mapped into the corresponding > > attribute of an object that exist only for the current thread. Yet you > > see that all code outside functions is executed only once when the web > > server starts and before any request arrives. All code that accesses > > the thread local proxies (request, session, etc) is in functions and > > they must be called explicitly. > > > web2py allows to have code in models that is not in any function > > therefore you do not need to call it. We can think of it as app level > > global variables. This is the point I was making before. > > > We use something similar to thread local vars inside the DAL since > > connection objects are thread locals. We just do not user a proxy > > class but an dictionary mapping between thread_id and connection > > objects. > > > Anyway, the idea of thread local proxy is really nice and I will think > > if we can take advantage of it. > > > Massimo > > > On Jun 10, 7:03 pm, Thadeus Burgess <thade...@thadeusb.com> wrote: > > > > > This code MUST be executed. There is no way to import it because > > > > request.client only exist when the request arrives and we do not want > > > > to re import modules on every request. > > > > Flask accomplishes this perfectly by placing the request in a context > > > thread local. It only exists the the thread local when a request > > > actually arrives. > > > > So from flask import request will fail if there is actually no request! > > > > I am learning more about thread locals at the moment, but it seems > > > reasonable enough and it works. > > > > -- > > > Thadeus
