[Yum-devel] [PATCH] Avoid dangling iterators if auto_close is used
Panu Matilainen
pmatilai at laiskiainen.org
Mon Feb 14 15:15:08 UTC 2011
On 02/14/2011 04:31 PM, James Antill wrote:
> On Sun, 2011-02-13 at 16:51 +0200, Panu Matilainen wrote:
>> On Fri, 11 Feb 2011, James Antill wrote:
>>>
>>> Gah, another reason to hate auto_close ... ACK.
>>> Can you add a comment to the ts.close() calls though, saying something
>>> like "note all 'mi' have to be gone when we call this" or something.
>>
>> Here's an alternative approach you might find more attractive, as instead
>> of adding yet more cruft it:
>> - hides away auto_close inside a single function
>> - eliminates the dangling iterator issue
>> - removes code duplication by handling gpg-pubkey filtering centrally
>> - should be compatible with all historical rpm brokenness in this area
>
> ACK, for the code. Although the indentation seems weird in a few places
> (Eg. _all_packages() doesn't look like it should need -+ lines).
The patch seems to have gotten a bit mangled by email, sorry about that.
The _all_packages() part seems a bit funny because _get_packages() does
pretty much what _all_packages() used to do, and now _all_packages
simply becomes a call to _get_packages() with no arguments.
Anyway, the patch wasn't really intended for submission as-is but more
to get a "preliminary ack" on the idea. With the ack gotten, I'll polish
it up a bit (at least the *args, **kwds argument shuffle for dbMatch()
is uuuuugly)
>> _header_from_index() could be converted to use this too, but if it's
>> expected to return headers for gpg-pubkeys too then _get_packages() will
>> need a switch to enable/disable the filtering.
>
> That should be fine, although _header_from_index() is a dead function
> anyway. As long as returnGPGPubkeyPackages works, it's all good :).
Is there a reason to actually keep it around since it's dead and
apparently an internal-only function at that? I can update that part
too, but I prefer removing dead code to patching it :)
- Panu -
More information about the Yum-devel
mailing list