Yes may be session was locked , thats why session.current=processing_path not working
But then again , while processing files i try opening separate page , to other controller , it was waited till the first (file Crawler) page finished parsing. ok i will make a separate thread about this. On 8/25/10, mdipierro <[email protected]> wrote: > > > On Aug 25, 11:00 am, Phyo Arkar <[email protected]> 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 <[email protected]> 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 <[email protected]> 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
