On Jan 19, 10:14 am, ae <ae88...@gmail.com> wrote:
> Well, maybe not. I just downloaded 1.91.6 and I couldn't replicate
> the behavior. We use 1.67.1 in production and what I tested on might
> have been even older than that.
So I'm back to not sure again. When I tested earlier I used the --
maxthreads option, but looking at it more carefully, it appears that --
maxthreads has no effect unless you also pass --minthreads (I'm on
Linux).
Even so, I was able to have three browsers open, each blocking one of
two threads. The third would request a fast-running function and it
was able to use whichever thread was freed first. For better or
worse, it appears that one user can now use multiple threads at the
same time (but only if calling different functions).
I ran into an odd scenario:
web2py is started with --minthreads=2 --maxthreads=2
lets say applications/test/controllers/default.py looks like:
def sleeper():
import time
time.sleep(60)
return str(time.time())
def gethi():
return "hi"
You have two PCs: pc1, pc2
In a browser window with 2 tabs, pc1 hits sleeper() in each tab.
pc2 tries to hit gethi() but is blocked.
After about 60 seconds in tab1 on pc1, the function returns.
Then, pretty fast, pc2's call to gethi() returns.
Then after about 60 more seconds, pc1's second tab's call to sleeper()
returns.
It sounds like only 1 thread was used. This seems like a bug--as if
there's a counter of the number of threads and the counter was
decremented and then the server decided that a single browser couldn't
run the same function in different threads at the same time. The
third came along and even though the second thread was free, it wasn't
used.
>From two different browsers on the same host, I was able to use two
threads and block a third browser on a different host. The third
browser seemed to get whichever thread finished first. That's good.
It doesn't seem like I'm going to get predictable behavior, so I guess
I should just not execute any long-running functions.
