fatal error: concurrent map writes

[kalbasit]

fatal error: concurrent map writes

goroutine 3765 [running]:
runtime.throw(0xcf6ade, 0x15)
        /usr/local/go/src/runtime/panic.go:596 +0x95 fp=0xc42098f828 sp=0xc42098f808
runtime.mapassign(0xc03600, 0xc4208f6030, 0xc42098f8f0, 0xba2b40)
        /usr/local/go/src/runtime/hashmap.go:499 +0x667 fp=0xc42098f8c8 sp=0xc42098f828
github.com/rs/xlog.(*logger).SetField(0xc4208f6000, 0xceccc8, 0xa, 0xba2b40, 0xc4202aa600)
        /go/src/github.com/rs/xlog/xlog.go:234 +0x66 fp=0xc42098f910 sp=0xc42098f8c8

[kalbasit]

we should either protect the logger with a mutex or use sync.Map with Go 1.9.

[iscander]

or provide a recommendation for best usage practice or workaround:
logger.Infof("Format ...", arg1, arg2,...argN, xlog.F{"key": "value",..."keyM": "valueM"})

[tomsid]

@rs could you confirm that it's a bug that should be fixed and not by design (for performance reasons)?

[rs]

If you need to change a logger in a different go you are supposed to either pass a copy of the logger.

I recommend to switch to zerolog which is better designed and a lot faster btw.

[kalbasit]

@rs we ended up with zerolog, this problem went away when we did that.

[tomsid]

Yeah, that could be a solution, thanks. But what about that issue? Is that something that should be fixed? If not it would be nice to document that behavior.

Unfortunately can't do it as it takes too much effort, but thanks for the recommendation.

[rs]

Generally, when something is not documented as thread safe, it is caller’s job to ensure safety.