I was not able to find any notes on thread-safety of Span in the Specification, nor in opentracing-java.
Problem
I'm not sure if I could use single Span instance in a concurrent environment. When discussed on Gitter with @jpkrohling, he said he would expect it to be thread-safe, but in practice it is probably implementation-specific as thread-safety it not explicitly addressed in the Specification.
Considering operations from opentracing-java
I guess the Span#finish operation can be thought of as thread-safe as it should be called only once
I'm not sure about other operations (Span#log, Span#setTag etc.)
For other Data Models I've found that
SpanContext is thread-safe, because is it required to be immutable by Specification
Clarify in the specification, whether OpenTracing implementations should (or must) implement Span and it's operations in a thread-safe manner. And vice versa, if thread-safety is intentionally implementation dependent, it should be mentioned in the docs (or opentracing-java at least)
Background
I was not able to find any notes on thread-safety of Span in the Specification, nor in opentracing-java.
Problem
I'm not sure if I could use single Span instance in a concurrent environment. When discussed on Gitter with @jpkrohling, he said he would expect it to be thread-safe, but in practice it is probably implementation-specific as thread-safety it not explicitly addressed in the Specification.
Considering operations from opentracing-java
For other Data Models I've found that
Proposal
Clarify in the specification, whether OpenTracing implementations should (or must) implement Span and it's operations in a thread-safe manner. And vice versa, if thread-safety is intentionally implementation dependent, it should be mentioned in the docs (or opentracing-java at least)
Thanks!