Interesting. I like the analogy in that StackOverflow post. I've been watching David's video from his previous talk on the GIL. It seems like unless a thread gives up the GIL somehow, it would be hard to have a long-running thread on one request without hanging up other threads.
Using a separate process seems like the best option, though turning the thing into an asynchronous process adds a layer of UX complexity that I'd hope to avoid. Also, a post from Tornado's developers on the subject: https://github.com/facebook/tornado/wiki/Threading-and-concurrency On Mar 4, 4:24 pm, Ricardo Pedroso <[email protected]> wrote: > On Sat, Mar 3, 2012 at 5:54 AM, Massimo Di Pierro > > <[email protected]> wrote: > > Not sure I understand the issue but you should not have time.sleep in code. > > It causes the threads to live longer then necessary and make you vulnerable > > to DoS attacks. > > Of course, sleep is more like a simple hack. If the app is for internal use > with > few users that might be worth it. > > > If you need to do something computationally expensive you need to use the > > scheduler and perform the tack using a background process. > > The ideal solution. > CPU intensive task should not be handled within requests. > > > Anyway, one slow request should not slow down other requests unless: > > 1) the other request are performed by the same user (in this case the > > session is locked unless you session._unlock(response)) > > 2) the slow process keeps the database locked (you can unlock it by adding > > db.commit() after each db insert/delete/update) > > 3) If using a python webserver that runs in one process, > even with multiple threads, if there is a CPU intensive task and > GIL is not released, other threads may not be able to run. > > for example put this in a controller, unrealistic code: > > import time > def index(): > n = 1000000000 > while n > 0: > #time.sleep(0.001) > i = range(1000000) > n -= 1 > return "Teste" > > Suppose the app is named test, run the function,http://localhost:8000/test > then try to access the welcome app,http://localhost:8000/welcome/default/index > The welcome will be served, but after a long time. > > If we comment the i = range(1000000) line, than welcome will be served > more quickly. > Why? It's still a heavy CPU task. > I suppose that it is due to python ticks (import sys;sys.getcheckinterval()). > The range line will slow down the tick count. > > For more detailed explanation > see:http://www.dabeaz.com/python/UnderstandingGIL.pdf > > I'm not 100% sure about this stuff, so if something is not correct, > or you can improve on this subject, please do. > > Note, these tests were done with rocket server, > that use one process with several threads. > > I found an interesting explanation about > webservers:http://stackoverflow.com/a/3491931 > > Ricardo
