You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is a good thing as it allows you to see any code which might be partly broken when this is not apparent. Orchestrator does not generally use a lot of CPU so even running the binary with the race detector enabled has little overhead. Making it easy to do this by adjusting build.sh seems handy and basically requires the go build ... to be changed to go build -race ...
The text was updated successfully, but these errors were encountered:
As quick followup, @sjmudd tested and found that with -race there is a limit of 8192 concurrent goroutines. At @sjmudd 's workplace this is actually a reasonable number, hence -race si not applicable to his case.
It is therefore not applicable in the general case. I'm closing this.
Actually that error only happens if you have a very high concurrency. Most people should not see that, and in any case the idea was to have this as an optional build flag to build.sh, thus avoiding people having to adjust the build.sh to get a race-detector enabled binary. This would not be enabled normally but it would be useful as I have seen some races come up when running the stock orchestrator code with this enabled.
This is a good thing as it allows you to see any code which might be partly broken when this is not apparent. Orchestrator does not generally use a lot of CPU so even running the binary with the race detector enabled has little overhead. Making it easy to do this by adjusting build.sh seems handy and basically requires the go build ... to be changed to go build -race ...
The text was updated successfully, but these errors were encountered: