Need for shutdown_async?

[cijothomas]

PeriodicReader and BatchProcessors have been redesigned to create own Thread and make blocking calls from within it.
A shutdown is triggered by the Drop, which can block user thread. Options

1. Offer a shutdown_async() variant, which users can invoke themselves and await. Once shutdown is already initiated, drop will not re-attempt, so there won't be a concern about Blocking user threads.
2. Have users rely on methods offered by async runtimes like tokio::spawn_blocking to invoke shutdown.

Opening a tracking issue to collect feedback on this, before exposing a new API.

[lalitb]

The providers currently do not offer any async API. I would vote to keep the existing design and allow users to rely on async blocking mechanisms to invoke shutdown (i.e. option 2 above).

[berkus]

Drop of the collectors is usually happening on shutdown of the whole thing, where waiting a few extra time units doesn't matter much, synchronous Drop is fine.

[sandersaares]

Yeah, blocking on drop/shutdown might be acceptable if there is a guarantee this never calls back into user code (i.e. that it only depends on the background task completing). In other words, the assumption should be that no user threads will execute while some OTel call is blocking (as in some execution environments, the OTel call would be preventing execution of user code).

This assumes that there are no async calls made into a user-provided runtime or similar. I suppose that is true? Main risk is that if OTel authors might want to change this in a future version, in which case there might be compatibility problems.