The problem is only if have two http request from the same client in the same session
A arrives loads session and unlocks B arrives loads session and unlocks A change session and saves it B changes session and saves it Nothing breaks but B never sees changes made by A and they are overwritten by B. With locks A arrives loads session B arrives and waits A change session and saves it B loads session (with changes made by A) B changes session and saves it On Aug 25, 3:52 pm, Jonathan Lundell <jlund...@pobox.com> wrote: > 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
