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

[WIP] Fix race condition when importing typelibs on Windows #3711

Open
wants to merge 13 commits into
base: master
Choose a base branch
from

Conversation

grossag
Copy link
Contributor

@grossag grossag commented Jun 23, 2020

On Windows, if a file #import's a type library, the compiler automatically generates .tlh and .tli files in the build directory. The compiler does not synchronize writes of these files so they should be considered side effects. They unfortunately have timestamps and absolute paths in them so (1) they are not cacheable and (2) cannot be considered as sources or they will cause unnecessary cache misses. However, setting them as normal SCons side effects would cause all files with the same target directory with that dependency to no longer be executed in parallel.

My solution is to introduce the idea of a temporary side effect. This effectively prevents all nodes with that side effect from executing at the same time until one node has successfully run. Once one node has successfully run, then it is no longer considered to be a side effect because it is already generated.

Fixes #2161

Contributor Checklist:

  • I have created a new test or updated the unit tests to cover the new/changed functionality.
  • I have updated CHANGES.txt (and read the README.rst)
  • I have updated the appropriate documentation

On Windows, if a file #import's a type library, the compiler automatically
generates .tlh and .tli files in the build directory. The compiler does not
synchronize writes of these files so they should be considered side effects.
They unfortunately have timestamps and absolute paths in them so (1) they
are not cacheable and (2) cannot be considered as sources or they will cause
unnecessary cache misses. However, setting them as normal SCons side effects
would cause all files with the same target directory with that dependency
to no longer be executed in parallel.

My solution is to introduce the idea of a temporary side effect. This
effectively prevents all nodes with that side effect from executing at the
same time until one node has successfully run. Once one node has successfully
run, then it is no longer considered to be a side effect because it is already
generated.
Not sure if this should go in SCons.Platform instead.
…ependency

The temporary side effect's "sources" entry wasn't being cleared after it was
processed. This was a problem when postprocessing the temporary side effect
for the second binary afterwards because the code tried to remove the temporary
side effect from sources of the first binary, when it had already been handled.
A test is included that consistently failed without the fix.
If a file was scanned after the temporary side effect expired, the temporary
side effect was being added again despite it not being necessary. Fix that by
not setting temporary side effects if they are already up-to-date.
An empty directory side-effect is up-to-date so it's not a good fit for a test
related to temporary side effects. Change it to a file.
@grossag grossag changed the title [WIP] Fix race condition when importing typelibs on Windows (PR 2161) Fix race condition when importing typelibs on Windows (Issue 2161) Nov 19, 2020
@grossag
Copy link
Contributor Author

grossag commented Nov 19, 2020

I didn't change doc/user/sideeffect.xml but I can if you all would like me to. Just let me know.

@mwichmann
Copy link
Collaborator

How does this stuff relate to TypeLibrary()? I presume that one is for building those while yours is for consuming them? I'd say a little more doc tying them together would be good. sideeffect.xml hasn't been picked up by the doc build before now, but recent changes do include it.

@grossag
Copy link
Contributor Author

grossag commented Nov 19, 2020

How does this stuff relate to TypeLibrary()? I presume that one is for building those while yours is for consuming them? I'd say a little more doc tying them together would be good. sideeffect.xml hasn't been picked up by the doc build before now, but recent changes do include it.

Yeah, that's right; TypeLibrary() builder produces typelibs while this change is related to importing typelibs. I'll think through how best to link the two in docs.

@grossag grossag changed the title Fix race condition when importing typelibs on Windows (Issue 2161) [WIP] Fix race condition when importing typelibs on Windows (Issue 2161) Jan 4, 2021
@mwichmann mwichmann linked an issue Mar 28, 2021 that may be closed by this pull request
@mwichmann mwichmann changed the title [WIP] Fix race condition when importing typelibs on Windows (Issue 2161) [WIP] Fix race condition when importing typelibs on Windows Mar 28, 2021
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.

Race condition with #import
2 participants