From a user standpoint, what does this new proposed approach entail? Post [#594], users would instantiate either the sync or async spanprocessor. Is the proposed change to instead expose an API call to either force flush sync/async, and then use the appropriate spanprocessor behind the scenes?

To bring up @mauriciovasquezbernal 's point, should we really have concurrency implemented in the MultiSpanProcessor level as opposed to individual spanprocessors themselves? An argument for this would be control to the implementor (for any custom spanprocessors they might want to implement) and lets them decide themselves whether or not to block. An argument against would be if we believe that our SDK should NEVER block, and let the concurrency/nonconcurrent controls be the responsibility of the sdk itself. In that case should all spanprocessors implemented be inherently synchronous since the control is left to the SDK?

This issue was marked stale due to lack of activity. It will be closed in 30 days.

Closed as inactive. Feel free to reopen if this issue needs resolving.