Re: [oe] Multiple bitbake and a shared DL_DIR location - race conditions?
Richard Purdie <rpurdie <at> rpsys.net>
2008-03-02 19:19:28 GMT
On Sun, 2008-03-02 at 19:52 +0100, Leon Woestenberg wrote:
> Hello Koen,
> > | I would like to allow the builds to overlap in time, at least make
> > | sure the builds are robust to this, but I doubt this is possible at
> > | all.
> > |
> > | Are there any race conditions with the current approach?
> > |
> > | I.e. what if two fetch tasks from concurrent instances of bitbake
> > | decide to download a package?
> > Isn't that what the .lock files are supposed to do? If you have multiple
> > bitbake threads (in one bitbake instance) it has to solve the same problem.
> Maybe, I did not fully understand how the go() function in
> "lib/bb/fetch/__init__.py" could handle this case:
> Suppose at time T one bitbake instance #1 is downloading/fetching
> package A, and bitbake instance #2 at time T would like to fetch the
> same package, what will #2 do?
> Will it wait for the lock to be released, then check?
Yes, it should but see my comment about scm checkouts too. Ultimately
I'd like bitbake to have more awareness of locks and take it into
account when scheduling tasks. In reality I'll settle for it working
without races at the moment .