Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Avoid race condition #813

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Avoid race condition #813

wants to merge 1 commit into from

Conversation

bmwiedemann
Copy link

There seems to be some race-condition in build.rs
that causes random build results to be produced for /usr/bin/difft.

This change seems to have negligible influence on overall build time.

If you make a better patch, I can test it.

There seems to be some race-condition in build.rs
that causes random build results to be produced for `/usr/bin/difft`.

The change seems to have negligible influence on overall build time.

This patch was done while working on reproducible builds for openSUSE.

Co-authored-by: Andrea Manzini <[email protected]>
Copy link
Owner

@Wilfred Wilfred left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the PR!

Can you share more information? Are you getting invalid binaries, or valid but not bit-for-bit identical binaries? What platform are you building on?

I'd also be surprised if building all the C libraries in parallel wasn't still a big improvement for build time. Try removing .flag_if_supported("-Wno-unused-parameter") from build.rs and see if the build time is comparable with and without your change.

@bmwiedemann
Copy link
Author

It produced different binary results. Probably all working, but did not test. I think, some elements were ordered differently.

You can use https://github.com/bmwiedemann/reproducibleopensuse/blob/master/filterdiff with 'strings' and difft binaries as params. (and the diff is probably more readable with lto = "off" )

I measured build times on a 2x16 core 2.6GHz host with build VMs:
without patch on 1-core-VM: 657s
with patch on 1-core-VM: 654s
without patch on 4-core-VM: 142s
with patch on 4-core-VM: 175s

So the patch does slightly speed up single-core builds but slow down multi-core builds. If we can avoid the variations in other ways, that would be good.

-Wno-unused-parameter seems to not make a difference.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants