AW: AW: DorothyLocker and performance
"Bauer, Georg" <[email protected]> Wed, 29 Sep 2004 13:47:50 +0200
| Newsgroups | gmane.comp.pythin.pyds.devel |
|---|---|
| Message-ID | <C43D74B62BA19A45ADD74C1AB7AEE5427998A2@NT-GWS2> |
Hi! Ok, that one works now. Commited to CVS. Thanks. bye, Georg -----Urspr=FCngliche Nachricht----- Von: Thomas Klaeger [mailto:[email protected]] Gesendet: Mittwoch, 29. September 2004 13:33 An: Bauer, Georg Cc: 'Garth T Kidd'; 'PyDS Developer List (E-Mail)' Betreff: Re: AW: [Pyds-dev] DorothyLocker and performance Hello! My favority patch: thread.lock.acquire() returns nothing if called without argument,=20 according to the docs for python 2.2/2.3, even if on win32 it seems to=20 return something. The attached patch calls thread.lock.acquire(1), which returns true if=20 the acquiration succeded, so the following assert won't fail. Regards, Thomas Bauer, Georg schrieb: > Hi! >=20 > I now get the following. Looks like the _acquire fails in = DorothyLocker - > but I don't know why. Without DorothyLocker it works fine. Another = 2.2 > problem? >=20 > bye, Georg >=20 > _acquire:=20 > Exception exceptions.AssertionError:=20 > ('/opt/pyds/lib/python2.2/site-packages/PyDS/Tool.py', 1393, = '_acquire', > 'return self.lock.acquire(blocking)') > ('/opt/pyds/lib/python2.2/site-packages/PyDS/DorothyLocker.py', 342, > 'acquire', 'assert result # ... but you can never be too careful.') > ----------------------- > ReleaseOfUnAcquiredLock > ----------------------- > An attempt to release an un-acquired lock. Probably caused by failure = to > acquire. > Detection context: > File "/opt/pyds/lib/python2.2/site-packages/PyDS/EventsTool.py", = line 93, > in _log > File "/opt/pyds/lib/python2.2/site-packages/PyDS/EventsTool.py", = line 99, > in _logVerbose > File "/opt/pyds/lib/python2.2/site-packages/PyDS/Tool.py", line = 1631, in > logVerbose > File "/opt/pyds/lib/python2.2/site-packages/PyDS/Tool.py", line = 1322, in > thunk > File "/opt/pyds/lib/python2.2/threading.py", line 396, in run > File "/opt/pyds/lib/python2.2/threading.py", line 408, in = __bootstrap > Exception in thread aggregator: > Traceback (most recent call last): > File "/opt/pyds/lib/python2.2/threading.py", line 408, in = __bootstrap > self.run() > File "/opt/pyds/lib/python2.2/threading.py", line 396, in run > apply(self.__target, self.__args, self.__kwargs) > File "/opt/pyds/lib/python2.2/site-packages/PyDS/Tool.py", line = 1322, in > thunk > tool.logVerbose(_('Background process started')) > File "/opt/pyds/lib/python2.2/site-packages/PyDS/Tool.py", line = 1631, in > logVerbose > getTool('events')._logVerbose(self.name, msg) > File "/opt/pyds/lib/python2.2/site-packages/PyDS/EventsTool.py", = line 99, > in _logVerbose > self._log(tool, message) > File "/opt/pyds/lib/python2.2/site-packages/PyDS/EventsTool.py", = line 93, > in _log > finally: self._release() > File "/opt/pyds/lib/python2.2/site-packages/PyDS/Tool.py", line = 1407, in > _release > return self.lock.release() > File "/opt/pyds/lib/python2.2/site-packages/PyDS/DorothyLocker.py", = line > 363, in release > self.__sanity_check('release', my_context) > File "/opt/pyds/lib/python2.2/site-packages/PyDS/DorothyLocker.py", = line > 290, in __sanity_check > raise ReleaseOfUnAcquiredLock, (None, my_context) > ReleaseOfUnAcquiredLock: (None, <PyDS.DorothyLocker.CallingContext = object at > 0x8927614>, 'An attempt to release an un-acquired lock. Probably = caused by > failure to acquire.') >=20 > bye, Georg >=20 > -----Urspr=FCngliche Nachricht----- > Von: Garth T Kidd [mailto:garth-OnzZ1s1DREKDegMON/[email protected]] > Gesendet: Dienstag, 28. September 2004 22:29 > An: 'Bauer, Georg'; 'Thomas Klaeger' > Cc: 'PyDS Developer List (E-Mail)' > Betreff: RE: [Pyds-dev] DorothyLocker and performance >=20 >=20 > cvs diff -c PyDS\DorothyLocker.py > 20040928-2222-dorothyagain.diff >=20 > I've updated, backed out the conflict damage (CVS deciding to replace whole > sections of identical code when only __revision__ had changed), and > re-generated. Attached.=20 >=20 > I'm beginning to like unit tests. It was quite reassuring to run the module > under 2.2 and see a line of dots followed by OK. I'd otherwise have = spent a > lot of time stressing that I had some *other* 2.2 compatibility = issues > somewhere. I can't run PyDS up wholesale under 2.2 because all my = third > party libraries are loaded for 2.3...=20 >=20 > -----Original Message----- > From: pyds-dev-admin-iYtK5bfT9M//Ad8WF/[email protected] > [mailto:pyds-dev-admin-iYtK5bfT9M//Ad8WF/[email protected]] On Behalf Of Bauer, = Georg > Sent: Wednesday, 29 September 2004 1:02 AM > To: 'Garth T Kidd'; 'Thomas Klaeger' > Cc: 'PyDS Developer List (E-Mail)' > Subject: AW: [Pyds-dev] DorothyLocker and performance >=20 > Hi! >=20 > Sorry, but that's not a patch against the current CVS. That patch = can't be > merged because it contains stuff that was already applied or = something like > that: >=20 > bash-2.05a$ patch --dry-run -p0 <20040928-2222-dorothyagain.diff = patching > file PyDS/DorothyLocker.py Reversed (or previously applied) patch detected! > Assume -R? [n] n Apply anyway? [n] y Hunk #1 FAILED at 1. > Hunk #2 FAILED at 37. > 2 out of 2 hunks FAILED -- saving rejects to file PyDS/DorothyLocker.py.rej > bash-2.05a$ patch --dry-run -p0 <20040928-2222-dorothyagain.diff = patching > file PyDS/DorothyLocker.py Reversed (or previously applied) patch detected! > Assume -R? [n] y Hunk #2 FAILED at 21. > 1 out of 2 hunks FAILED -- saving rejects to file PyDS/DorothyLocker.py.rej >=20 > bye, Georg >=20 > -----Urspr=FCngliche Nachricht----- > Von: Garth T Kidd [mailto:garth-OnzZ1s1DREKDegMON/[email protected]] > Gesendet: Dienstag, 28. September 2004 14:23 > An: 'Bauer, Georg'; 'Thomas Klaeger' > Cc: 'PyDS Developer List (E-Mail)' > Betreff: RE: [Pyds-dev] DorothyLocker and performance >=20 >=20 > That's a weird one.=20 >=20 > Oh, hang on. >=20 > E.E..E.........E.E....E >=20 > Yep. Python 2.2 works differently to Python 2.3. Here's a fix.=20 >=20 > -----Original Message----- > From: pyds-dev-admin-iYtK5bfT9M//Ad8WF/[email protected] > [mailto:pyds-dev-admin-iYtK5bfT9M//Ad8WF/[email protected]] On Behalf Of Bauer, = Georg > Sent: Tuesday, 28 September 2004 5:24 PM > To: 'Garth T Kidd'; Bauer, Georg; 'Thomas Klaeger' > Cc: PyDS Developer List (E-Mail) > Subject: AW: [Pyds-dev] DorothyLocker and performance >=20 > Hi! >=20 >=20 >>Oh, did I forget to send that one in? Sorry. :| I had that, = alternative=20 >>logging for those post-shutdown logs, and code to make sure = EventsTool=20 >>was last. >=20 >=20 > Your patch wasn't able to be applied - I wrote you this directly and > off-list :-) >=20 > My solution is a bit more flexible, though: you now have a flag to = tell > where to sort the tool on shutdown. I use that to move the = PreferencesTool > directly before EventsTool so that the preferences can be still = fetched > until the very last moment in shutdown. >=20 >=20 >>You're calling PyDS.Tool.getToolsForShutdown twice, just like you = used=20 >>to getTools. Is there anything wrong with saving the value and using = it >=20 > twice? >=20 >=20 > Changed that, although it really doesn't matter much - the shutdown = is only > called once in a running instance ;-) >=20 >=20 >>Could you drop in this latest version of DorothyLocker? You're now a=20 >>fair way behind, and I've lost track of when I fixed certain bugs. = That=20 >>might >=20 >=20 > Did that. But it would really be a bit better if you stick to CVS mechanisms > - just do an update and merge in the changes I commited and then = reproduce > your patch with regard to current CVS. It's much more likely that I = put in a > working patch than full module sources, as the latter would require = me to > make the diff myself to see what changed. And I am known to be lazy = ;-) >=20 > For example this time: after adding the full module I could'nt start = PyDS, > because of some changes to the interface of DorothyLocker that = required > additional patches. But your patch didn't work, as your full module already > was installed. Mixing different patch/dist methods allways makes = things more > complicated. >=20 > Oh, and now the CVS is broken. One thing was a small typo in Tool.py (wrong > indention) that was easily fixed. But now it barfs about "sequence = must be > integer" on start. What's that? It happens in your __getitem__ method = in > your FramingContext where it accesses the framestack (line 103). = Looks like > ltrim_common doesn't produce integers as index somehow (maybe pos not > initialized?). This happens directly at startup of PyDS: >=20 > Exception exceptions.TypeError: sequence index must be integer > ('/opt/pyds/lib/python2.2/site-packages/PyDS/Tool.py', 1407, = '_release', > 'return self.lock.release()') > ('/opt/pyds/lib/python2.2/site-packages/PyDS/DorothyLocker.py', 359, > 'release', "self.__sanity_check('release', my_context)") > ('/opt/pyds/lib/python2.2/site-packages/PyDS/DorothyLocker.py', 260, > '__sanity_check', 'lock_uniques, my_uniques =3D = ltrim_common(lock_context, > my_context)') > ('/opt/pyds/lib/python2.2/site-packages/PyDS/DorothyLocker.py', 54, > 'ltrim_common', 'return oblist1[pos:], oblist2[pos:]') > ('/opt/pyds/lib/python2.2/site-packages/PyDS/DorothyLocker.py', 103, > '__getitem__', 'return self.framestack[index]') Traceback (most = recent call > last): > File "/opt/pyds/bin/pyds-start", line 51, in ? > PyDS.Server.start_server(daemon=3D_PyDS.daemon) > File "/opt/pyds/lib/python2.2/site-packages/PyDS/Server.py", line = 298, in > start_server > PyDS.Tool.initTools(PyDS.Tool.mainstatus) > File "/opt/pyds/lib/python2.2/site-packages/PyDS/Tool.py", line = 317, in > initTools > tool._initdb() > File "/opt/pyds/lib/python2.2/site-packages/PyDS/WeblogTool.py", = line 77, > in _initdb > finally: self._release() > File "/opt/pyds/lib/python2.2/site-packages/PyDS/Tool.py", line = 1407, in > _release > return self.lock.release() > File = "/opt/pyds/lib/python2.2/site-packages/PyDS/DorothyLocker.py", > line 359, in release > self.__sanity_check('release', my_context) > File = "/opt/pyds/lib/python2.2/site-packages/PyDS/DorothyLocker.py", > line 260, in __sanity_check > lock_uniques, my_uniques =3D ltrim_common(lock_context, = my_context) > File = "/opt/pyds/lib/python2.2/site-packages/PyDS/DorothyLocker.py", > line 54, in ltrim_common > return oblist1[pos:], oblist2[pos:] > File = "/opt/pyds/lib/python2.2/site-packages/PyDS/DorothyLocker.py", > line 103, in __getitem__ > return self.framestack[index] > TypeError: sequence index must be integer >=20 >=20 >=20 >>also be behind some of the performance hits you're seeing (I used the = >>latest, assuming you'd incorporated it after that submission I made=20 >>that >=20 > got >=20 >>blocked for size). >=20 >=20 > I usually write about what I commited (and at least it's in the CVS = RSS > feed). So if you don't see me mentioning it, it supposedly isn't in = CVS. I > either wasn't able to apply it (then I usually write something) or I = just > plain missed it. >=20 > bye, Georg >=20 >=20 > _______________________________________________ > Pyds-dev mailing list > Pyds-dev-iYtK5bfT9M//Ad8WF/[email protected] > http://www.westfalen.de/cgi-bin/mailman/listinfo/pyds-dev >=20 >=20 > _______________________________________________ > Pyds-dev mailing list > Pyds-dev-iYtK5bfT9M//Ad8WF/[email protected] > http://www.westfalen.de/cgi-bin/mailman/listinfo/pyds-dev >=20 >=20