This item doesn't appear to have a follow-up. On Wed, Oct 4, 2017 at 11:10 AM, Burton, Ross <[email protected]> wrote:
> On 3 October 2017 at 19:17, Peter Kjellerstedt < > [email protected]> wrote: > >> > + # Take shared lock since we're only reading, not writing >> > lf = bb.utils.lockfile(bb.data.expand("${PACKAGELOCK}", d)) >> >> Here, however, it is not changed, even though a comment is added to >> say that it is. Was this intentional, or just an oversight? >> >> > + # Take shared lock since we're only reading, not writing >> > lf = bb.utils.lockfile(bb.data.expand("${PACKAGELOCK}", d)) >> >> Here again a comment is added, but the code is not changed to match. > > > I'm no expert on this piece of code but that definitely looks like an > oversight. > > >> Also, what is the ${PACKAGELOCK} lock file actually protecting? With >> > the exception of the two questionable cases above, I cannot see that >> the lock is taken privately anywhere else. And since it looks as the >> code in package_do_shlibs() and package_do_pkgconfig() is not what >> needs protection (based on the added comments above), what is? >> > > Good point. The sstate locks are also shared. > > Richard was involved in all of these changes so lets wait for him to > return from his holiday... > > Ross > > > -- > _______________________________________________ > Openembedded-core mailing list > [email protected] > http://lists.openembedded.org/mailman/listinfo/openembedded-core > >
-- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
