Safe use of *LogBackend.Logger

[kevinjos]

Safe use of *LogBackend.Logger

[giftig]

I'd definitely hope it's threadsafe... I've been using it concurrently across several goroutines without problems, but I can't say definitively that it's okay as I haven't looked at the library's code in great detail. What say you, @op ?

[jaytaylor]

I know that concurrent writes to stdout are not safe. Afaik go-logging doesn't do anything to protect from this, but looking at the hot code path would give the definitive answer. I recall observing occasional malformed output from go-logging from what appeared to be concurrency issues in the past, but it's rare enough that I'm not worried for my needs.

On Jan 26, 2016, at 2:35 PM, giftig [email protected] wrote:

I'd definitely hope it's threadsafe... I've been using it concurrently across several goroutines without problems, but I can't say definitively that it's okay as I haven't looked at the library's code in great detail. What say you, @op ?

—
Reply to this email directly or view it on GitHub.

[op]

It should be safe to use from multiple goroutines. If not, it's a bug. Locks have been avoided due to performance reasons but the shared state should be thread-safe.

The log backend, which I guess most people are using, does only one call to the log package and the log package itself says that

A Logger can be used simultaneously from multiple goroutines; it guarantees to serialize access to the Writer.

See here: https://golang.org/src/log/log.go#L147 . For the other backends, eg syslog, I don't see why you shouldn't be able to use them from multiple goroutines either.

Order is not (currently) guaranteed if multiple backends are used but they should work fine.

@jaytaylor it would be interesting to know how how that is possible. What backends are you using? You should be able to run with race tracer to detect errors.