Use jobs flag to really control number of concurrent compilations
The issue was due to the peculiar way concurrency and parallelism are handled in go. We used to set GOMAXPROC to 1 to avoid parallelizing the WaitGroup execution. This would work, in theory, unless the goroutines sleep. In that case, another goroutine is allowed to start concurrently (only 1 goroutine running in parallel, so GOMAXPROC is happy). Since our goroutines sleep (wait) after calling gcc, another task is started, without any hard limit, till the WaitGroup is completely spawned. On systems with limited resources (as RaspberryPi) and cores with lots of files this can trigger an out of memory condition.
Showing
Please register or sign in to comment