Investigate async force flush approach for spanprocessors.

[toumorokoshi]

As part of #594, work was done to introduce two different MultiSpanProcessors: sync and async. Async uses a thread pool to be asynchronous.

@mauriciovasquezbernal argues that we may want to instead allow the caller to choose what sort of concurrency behavior to ask of the span processor (introducing a flush_force_async method):

#594 (comment)

Add this issue to discuss, and allow the PR to be merged in.

[lzchen]

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?

[github-actions]

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

[github-actions]

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