Thanks for the (quick) clarification.
On Jun 11, 12:33 am, mdipierro <mdipie...@cs.depaul.edu> wrote: > 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- Hide quoted text - > > - Show quoted text -
