On 2011/7/16 Dan McGee <dpmcgee@gmail.com> wrote:
On Sat, Jul 16, 2011 at 11:32 AM, Rémy Oudompheng <remyoudompheng@gmail.com> wrote:
Hello,
I am thinking an iterator-like interface for database reading could be useful. The most obvious example use is the pkgfile functionality. I don't disagree with the thinking.
It could be a convenient tool to do one-pass work on databases without loading them completely in memory, which can be impossible for databases with files info (I don't think everyone can load the whole [community] database using libalpm standard structures). Have you analyzed the heap using massif to see what is going on here? I doubt we break the ~65 MB mark (with one database), which is big, but not that ridiculous.
I guess the implementation below seems rather hacky to me, as it breaks at least two invariants we have: * Local DB entries are never loaded more than once
The goal here is not to change the behaviour of pacman, but to factorise the code so that it can be reused in other ways: the iterator implementation need not be public, if the interface exposes fixed usage patterns, e.g. mapping a function over all pmpkg_t.
* The caller is responsible for freeing the package (I think?)
The idea was that it would be used inside libalpm for two things: * loading the database * mapping a function over all packages without actually loading the database. So that there are two implementation patterns: * the iterator frees the previous package at each iteration (and the last package at the final iteration) * the iterator is private and the only public interface is a map() thing. -- Rémy.