On Aug 25, 11:00 am, Phyo Arkar <phyo.arkarl...@gmail.com> wrote: > Did I Read that reading files inside controller will block web2py , Does it?
No web2py does not block. web2py only locks sessions that means one user cannot request two concurrent pages because there would be a race condition in saving sessions. Two user can request different pages which open the same file unless the file is explicitly locked by your code. > Thats a bad news.. i am doing a file crawler and while crawling , > web2py is blocked even tho the process talke only 25% of 1 out of 4 > CPUs .. Tell us more or I cannot help. > > On 8/25/10, pierreth <pierre.thibau...@gmail.com> wrote: > > > I would appreciate a good reference to understand the concepts you are > > talking about. It is something new to me and I don't understand. > > > On 25 août, 11:22, John Heenan <johnmhee...@gmail.com> wrote: > >> No, nothing that abstract. Using WSGI forces a new thread for each > >> request. This is is a simple and inefficient brute force approach that > >> really only suits the simplest Python applications and where only a > >> small number of concurrent connection might be expected. > > >> Any application that provides web services is going to OS block on > >> file reading (and writing) and on database access. Using threads is a > >> classic and easy way out that carries a lot of baggage. Windows has > >> had a way out of this for years with its asynch (or event) > >> notification set up through an OVERLAPPED structure. > > >> Lightttpd makes use of efficient event notification schemes like > >> kqueue and epoll. Apache only uses such schemes for listening and Keep- > >> Alives. > > >> No matter how careful one is with threads and processes there always > >> appears to be unexpected gotchas. Python has a notorious example, the > >> now fixed 'Beazly Effect' that affected the GIL. Also I don't think > >> there is a single experienced Python user that trusts the GIL. > > >> John Heenan
