This is a bug. I fixed it in trunk. Thanks Jonathan.
On Aug 25, 9:30 pm, Jonathan Lundell <[email protected]> wrote: > On Aug 25, 2010, at 6:37 PM, mdipierro wrote: > > > > > The problem is only if have two http request from the same client in > > the same session > > Thanks for that; I was wondering under which conditions unlocking might be > permissible (and I'm still not entirely clear, but never mind for now). > > My concern is this. Here's unlock: > > def _unlock(self, response): > if response and response.session_file: > try: > portalocker.unlock(response.session_file) > response.session_file.close() > del response.session_file <<<<<------------------------- > except: ### this should never happen but happens in Windows > pass > > Now we save the session file: > > def _try_store_on_disk(self, request, response): > if response._dbtable_and_field \ > or not response.session_id \ > or self._forget: > self._unlock(response) > return > if response.session_new: > # Tests if the session folder exists, if not, create it > session_folder = os.path.dirname(response.session_filename) > response.session_file = open(response.session_filename, 'wb') > portalocker.lock(response.session_file, portalocker.LOCK_EX) > cPickle.dump(dict(self), response.session_file) > <<<<<<<<<---------------- > self._unlock(response) > > But response.session_file is None at this point. > > > > > 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 <[email protected]> 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 <[email protected]> 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 <[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
