Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Need for shutdown_async? #2476

Open
cijothomas opened this issue Dec 26, 2024 · 1 comment
Open

Need for shutdown_async? #2476

cijothomas opened this issue Dec 26, 2024 · 1 comment
Labels
A-common Area:common issues that not related to specific pillar

Comments

@cijothomas
Copy link
Member

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.

@cijothomas cijothomas added the A-common Area:common issues that not related to specific pillar label Dec 26, 2024
@lalitb
Copy link
Member

lalitb commented Dec 27, 2024

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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-common Area:common issues that not related to specific pillar
Projects
None yet
Development

No branches or pull requests

2 participants