On Aug 25, 2010, at 1:41 PM, mdipierro wrote: > > call > > session._unlock() > > if you do not need session locking
If you do that (without calling session.forget), what will happen in _try_store_on_disk when cPickle.dump(dict(self), response.session_file) is called with a None file argument? Or is cPickle.dump cool with that? Or am I misreading the logic? > > On Aug 25, 11:38 am, Phyo Arkar <phyo.arkarl...@gmail.com> wrote: >> 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 <mdipie...@cs.depaul.edu> wrote: >> >> >> >>> 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
