Workaround race contition in drawer.redrawMetrics()

[fedorlitau]

This is my current workaround I am using for the issue #111 (fatal error: concurrent map iteration and map write) to guard against concurrent access to the shared map StatusCodes accross ali and its library tsenart/vegeta

[nakabonne]

@fedorlitau Thank you for your discovery. The cause is definitely the data race on the StatusCode 👍

Your workaround solution is correct. It should perform correctly. But I have an idea that is simpler and goroutines don't block each other.
How about copying the StatusCode map when making a new Metrics (ali/attacker/metrics.go#L71) like:

 }

 func newMetrics(m *vegeta.Metrics) *Metrics {
+       codes := make(map[string]int, len(m.StatusCodes))
+       for k, v := range m.StatusCodes {
+               codes[k] = v
+       }
        return &Metrics{
                Latencies: LatencyMetrics{
                        Total: m.Latencies.Total,
@@ -98,7 +102,7 @@ func newMetrics(m *vegeta.Metrics) *Metrics {
                Rate:        m.Rate,
                Throughput:  m.Throughput,
                Success:     m.Success,
-               StatusCodes: m.StatusCodes,
+               StatusCodes: codes,
                Errors:      m.Errors,
        }
 }

The StatusCode map never gets huge, so the complexity of copying will be not that much.

[fedorlitau]

@nakabonne I'm glad I could point into the right direction =) I like the copy idea, because it also decouples ali's type Metrics from vegeta's more 👍

[nakabonne]

@fedorlitau Thank you. If you don't mind, could you work on that solution? Possibly, the above change will work well.

[fedorlitau]

Hey @nakabonne, sorry for the delay - I have created a new PR #115. Haven't tested it for hours, but first tests look good - no crashes.