On Aug 25, 2010, at 8:12 PM, Jonathan Lundell wrote: > > On Aug 25, 2010, at 7:56 PM, mdipierro wrote: >> >> This is a bug. I fixed it in trunk. Thanks Jonathan. > > It's fixed in the sense that it won't raise an exception. But now how is > calling _unlock different from calling forget?
Nag. > >> >> On Aug 25, 9:30 pm, Jonathan Lundell <jlund...@pobox.com> 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 <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 > >
