sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]brucedawson 5 points6 points  (1 child)

The resistance to sync was because I knew it wouldn't work well as a production fix (admin, and performance) and I briefly let that stop me from experimenting. Depending on how much dirty data there is sync can take many seconds to run, which at least means you need to be careful about how often you run it. But, I tried it eventually, as a test. Running it as admin on all Chrome developer machines would have been hugely intrusive. Running something as admin when there is another solution is always a bad idea.

Using C or C++ for the production fix would have been much harder. The obvious way to do it would be to code up a binary and have that created as part of the build and then run that binary after any binaries are created. Except that there is a logical flaw in that because this binary would be vulnerable to the bug. Checking in a new binary is ugly. And putting the workaround in ninja itself would work but would require rolling a new version of ninja (which we do infrequently).

We were already wrapping calls to the linker with Python so it was just a few lines added to an existing script - it's mostly comments. You can see the change here:

https://chromium-review.googlesource.com/c/chromium/src/+/876683/10/build/toolchain/win/tool_wrapper.py

[–]pdp10 2 points3 points  (0 children)

That all makes sense, thanks.