from the Tornado page "Tornado comes with limited support for WSGI.
However, since WSGI does not support non-blocking requests, you cannot
use any of the asynchronous/non-blocking features of Tornado in your
application if you choose to use WSGI instead of Tornado's HTTP
server."


On Jun 10, 11:33 pm, 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

Reply via email to