Conversation
|
Can you fix this without using locks? In most cases, these things are initialised first thing and doesn't require locks. |
|
Please fix this. We are using go-logging, and this issue keeps coming up for us. We use golang for the concurrency. There is a race condition flagged in the concurrent read/write access to the map. One module is trying to log a stmt(multi.go line 25 function Log, which calls IsEnabledFor), while another is initializing its logger (multi.go line 51, which calls SetLevel). There is a concurrent read/write to the map (level.go line 65, levels map[string]Level in type moduleLeveled struct). The library works awesomely, other than the intermittent failure it causes our application because of this race condition. |
|
In implementation of glog includes(C++, Golang), the vmoudle is fixed in running time.In C++ version glog, they use macro to make static anonymous variable in every module to store the log level.So i think if you want to fix this, change the moudle usage and some tricky technology should be required. |
go-logging is unmaintained since 2016 and has significant reentrancy problems causing crashes. See for example: op/go-logging#75 op/go-logging#102 op/go-logging#105 To fix this we introduce a wrapper for a subset of the go-logging library mapped on to Uber's zap logging library and switch to using that.
Data race test failed when in concurrent systems.
The test code can be found here: #74