Usage of block_on

[LukeMathWalker]

I noticed that SimpleSpanProcessor uses futures::executor::block to export a span every time it closes.
This can be troublesome when running on single-threaded executors (e.g. in tests), leading to a blocking of the executor thread itself. I have been experiencing several test hangs when using SimpleSpanProcessor that immediately vanish when using the batch exporter and global::shutdown.

I feel it would be more sensible to make SpanProcessor::on_end asynchronous:

• the simple exporter could simply await exporter.export;
• the batch exporter could keep pushing exporting jobs to a background task.

Unfortunately I am not familiar with the overall architecture of the crate, so I do not have an appreciation for the impact on the API of such a change (that's why I am opening an issue instead of a PR 😁 )

[djc]

Maybe review the interactions with #494 here?

[LukeMathWalker]

I looked at #494, but I think the two issues are orthogonal - am I missing something here?

[TommyCpp]

Yes #494 is unrelated. It aims to address the span drops problem when the volume of spans is too high. It doesn't really change anything in simple span processor

[jtescher]

#502 may resolve some of the issues around blocking here.

[jtescher]

@LukeMathWalker SpanProcessor::on_end now is a channel send in both span processors.