Danek this is great - we are not back in until Tuesday unfortunately
(I'm travelling atm).
Shawn would it be possible to spin a webrev to turn off the caching for
everything except pkg as you suggested below, so both fixes could get
into b101 on Monday?
We can work on our PM and UM changes on Tuesday, but the two above would
be great to get into b101.
Thanks,
JR
To do this, I would remove all of the use_cache changes you've made and
make the following simple changes to modules/client/image.py:
diff -r c95448e970e5 src/modules/client/image.py
--- a/src/modules/client/image.py Fri Oct 24 15:36:26 2008 -0500
+++ b/src/modules/client/image.py Fri Oct 24 15:42:28 2008 -0500
@@ -935,11 +935,14 @@
"""Find on-disk manifest and create in-memory Manifest
object, applying appropriate filters as needed."""
- if fmri in self.__manifest_cache:
- m = self.__manifest_cache[fmri]
+ if self.history.client_name == "pkg":
+ if fmri in self.__manifest_cache:
+ m = self.__manifest_cache[fmri]
+ else:
+ m = self.__get_manifest(fmri)
+ self.__manifest_cache[fmri] = m
else:
m = self.__get_manifest(fmri)
- self.__manifest_cache[fmri] = m
self.__touch_manifest(fmri)
Danek Duvall wrote:
> http://cr.opensolaris.org/~dduvall/pkg-memleak/
>
> This is the fix for the memory leak caused my by rewrite of the action
> parsing in C. It's pretty much all adding Py_DECREF() to a bunch of places
> in _actions.c.
>
> It passes the testsuite, it passes actionbench, and it demonstrates no
> increase in heap size when run through attachment 625 in bug 4116, which
> repeatedly creates the same action, periodically emitting RSS.
>
> It's even a bit faster than it was previously. Actionbench shows a 17%
> increase in speed in the "action creation" test, and a 6% increase in speed
> in the "manifest contents loading" test.
>
> Note that while all success paths are accounted for, and all paths that go
> raise a MalformedExceptionError are as well, there are some failure paths
> that don't do any reference (ac)counting. I believe that these will only
> happen in very rare cases -- such as out of memory, or corrupt memory --
> that are likely to cause the program to crash for other reasons, anyway.
> All the normal cases should be fine.
>
> If anyone can review this today or Sunday, that'd be fantastic -- it might
> just sneak into build 100. If not, then soon please, since 101 will follow
> shortly.
>
> Thanks,
> Danek
> _______________________________________________
> pkg-discuss mailing list
> [email protected]
> http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
>
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
