On Mon, Jun 06, 2011 at 02:05:14PM -0700, Brock Pytlik wrote: > On 06/04/11 17:14, Edward Pilatowicz wrote: > >hey all, > > > >i'm looking for a review of some quick and easy linked image performance > >fixes. > > > >http://mcescher.us.oracle.com/export/ws/pkg.perf2/webrev/ > > > >18489 skip generating parent deps if we're running a build with parent deps > >18490 sync-linked can be faster when there's nothing todo > >18491 noop packaging operations with li should run faster > >18293 linked image test test_err_pubcheck is noisy > > > >thanks > >ed > >_______________________________________________ > >pkg-discuss mailing list > >pkg-discuss@opensolaris.org > >http://mail.opensolaris.org/mailman/listinfo/pkg-discuss > client.py: > Is this change just fixing a cut/paste typo? If so, ok, if not, then > I don't understand why this is changing. >
yep. just fixing a typo. > imageplan.py: > 480: There's probably something here I just don't understand, but as > I understand things, the high level process is 1) plan the changes > in the parent image 2) plan the changes in each child image 3) > execute the changes. If that's the case, then how does audit_self > audit itself against the state the parent image is going instead of > the state it's in now? > for any given packaging operation there is only one set of "parent packages". ie, a child image doesn't have a concept of "old" parent packages and "new" parent packages. so when we're planning an operation in a parent image and we recurse into a child image, the "parent packages" that the child is aware of is the proposed/planned parent packages. so the audit audit is performed against the proposed/planned parent packages. > common.py: > 2229: If there's any chance of the command being run generating a > copious amount of error output, then a p.communicate() is probably > needed, otherwise there's a chance of deadlocking both processes. > Actually, even if you can't imagine how copious output could be > produced, p.communicate() is still probably called for because > debugging the deadlock condition would be rather difficult. > so i'm using a temporary file. i don't see how this can result in a deadlock. it seems much less error prone that a pipe (which can fill up, has signaling implications, etc). could you elaborate on the deadlock scenario you're thinking of? ed _______________________________________________ pkg-discuss mailing list pkg-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
