| ▲ | thomspoon 3 hours ago | |
The burden of proof should be with the beholder. Must be so easy to scream AI when you don’t want to read an article. | ||
| ▲ | thx67 2 hours ago | parent [-] | |
You obviously haven't read it, because it is clunky garbage. > 19.4 Pacing compiles after a failure > A failed compile is not free of side effects on the shared compile service. A compile that fails restarts the service, which takes a few seconds to come back, and failures that keep arriving faster than the service can restart between them keep it from making progress, so unrelated compiles slow down until the failures stop. The effect is a function of how fast failures arrive, not how many occur: failures spaced out past the restart interval cause no degradation at all. On detecting a failed compile, wait at least one restart interval, roughly 15 seconds, before the next compile, so a burst of failures cannot accumulate. No hard failure-count cap is needed. The whole document is less nutritious than a wonderbread miracle whip sandwich. | ||