Even with file reading there is no way the disk drive, its controllers and various buses can keep up with the CPU.
Hence reading any file from disk will cause the OS to intervene and block (reading a template view file, controller file or otherwise), albeit a 'short' time. Here are two choices. 1) Put the read function in a thread, wait for the thread to unblock and continue servicing any other threads that are no longer blocked. This is what web2py does using a Python file read. The OS automatically provides thread scheduling. 2) Tell the OS to pass a message to an event callback when the OS is ready. A separate thread is not required if the application chooses to process its own message queue as the thread in effect simply relays the message on. There is of course other blocks: file writing, database access and network read and write (including from/to the http request PC) It is tempting to say it is not rocket science. Anyway the main message is being aware of the plumbing and avoiding blind religious type fixations is important for long term planning and scalability issues. We really need to face up to realities that seeing Python as a black box type total solution is not healthy. John Heenan On Aug 26, 2:27 am, 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
