Comment 2 for bug 1696773
Revision history for this message
| Edward Vielmetti (edward-vielmetti) wrote | #2 |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
0e1f616
(Get the code!)
This bug is mentioned in this account from Cloudflare of porting their software stack to arm64:
https:/
The relevant section from that blog reads as follows:
# Intermittent Go Failures
> With a decent amount of Go code running through our CI system, it was easy to spot a trend of intermittent segfaults.
> Going on a hunch, we confirmed a hypothesis that non-deterministic failures are generally due to threading issues. Unfortunately, opinion on the issue tracker showed that Go / QEMU incompatibilities aren’t a priority, so we were left without an upstream fix.
> The workaround we came up with is simple: if the problem is threading-related, limit where the threads can run! When we package our internal go binaries, we add a .deb post-install script to detect if we’re running under ARM64 emulation, and if so, reduce the number of CPUs the go binary can run under to one. We lose performance by pinning to one CPU, but this slowdown is negligible when we’re already running under emulation, and slow code is better than non-working code.
> With the workaround in place, reports of intermittent crashes dropped to zero. Onto the next problem!