macports fetch suggestion

[Arno Hautala]

On Mon, Sep 12, 2011 at 02:40, Ryan Schmidt <ryandesign at macports.org> wrote:
>
> The useful idea suggested in the ticket is to fetch in a separate thread, while MacPorts is building other already-fetched ports, and this would indeed reduce the time it takes to build, but that would probably be difficult to implement without rewriting a lot of how MacPorts base works since we don't currently use threads. And even if I felt comfortable doing so, which I don't because I'm not that familiar with MacPorts base code or C or threads programming, I would be wary to do so, since it more or less works now, and I don't want to break it.

I'm not that familiar with base either, but I think one improvement
would be finer grained locking. It seems right now that only one
install or fetch command can be run at a time. But, it would seem to
me that these could be independently locked. You don't want to build
with multiple threads, but it should be fine to build one task, while
another task fetches. One issue could be if a database is updated
after the fetch which impacts a subsequent build task that has already
read the database. There's still probably plenty of race conditions
that would need to be examined, but finer grained locking might be an
easier step towards the goal.

-- 
arno  s  hautala    /-|   arno at alum.wpi.edu

pgp b2c9d448