FazBrowse GitHub Viewer | Trending |
URL:
| Home
Tools: [Download Repo ZIP]   [Original HTTPS Page]

Make sure the stream is alive in data callback. by flamme · Pull Request #2324 · google/oboe · GitHub

/ oboe Public

Make sure the stream is alive in data callback. - #2324

Merged
flamme merged 2 commits into
mainfrom
fix-2323
Oct 29, 2025
Merged

flamme merged 2 commits into
mainfrom
fix-2323

Conversation

flamme commented Oct 29, 2025

Copy link
Copy Markdown
Collaborator

Fixes #2323.

flamme requested a review from robertwu1 October 29, 2025 18:20

Copy link
Copy Markdown
Collaborator

How often does this happen in practice? If it happens often, should we revisit how we let apps hold callbacks when the stream ends?

flamme commented Oct 29, 2025

Copy link
Copy Markdown
Collaborator Author

How often does this happen in practice? If it happens often, should we revisit how we let apps hold callbacks when the stream ends?

It is always suggested apps should call close and wait for it to return until free the shared pointer. It is not related to stream ends.

Copy link
Copy Markdown
Collaborator

How often does this happen in practice? If it happens often, should we revisit how we let apps hold callbacks when the stream ends?

It is always suggested apps should call close and wait for it to return until free the shared pointer. It is not related to stream ends.

What happens when apps are forcefully closed? How do we handle this?

flamme commented Oct 29, 2025

Copy link
Copy Markdown
Collaborator Author

How often does this happen in practice? If it happens often, should we revisit how we let apps hold callbacks when the stream ends?

It is always suggested apps should call close and wait for it to return until free the shared pointer. It is not related to stream ends.

What happens when apps are forcefully closed? How do we handle this?

This is a different topic... Apps being forced stopping is not supposed to handle in this PR... If it is apps forcing stop, the application should have the right handle on their destroy process that will call close. If there is other reason that crashing the app and the app is not able to call close, it indicates more serious problem that is out of our scope here.

Copy link
Copy Markdown
Collaborator

How often does this happen in practice? If it happens often, should we revisit how we let apps hold callbacks when the stream ends?

It is always suggested apps should call close and wait for it to return until free the shared pointer. It is not related to stream ends.

What happens when apps are forcefully closed? How do we handle this?

This is a different topic... Apps being forced stopping is not supposed to handle in this PR... If it is apps forcing stop, the application should have the right handle on their destroy process that will call close. If there is other reason that crashing the app and the app is not able to call close, it indicates more serious problem that is out of our scope here.

Yes, I just wanted to bring this up. The change looks good to me.

flamme merged commit 7234afa into main Oct 29, 2025
3 checks passed
flamme deleted the fix-2323 branch October 29, 2025 19:33
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Keep the stream alive in data callback

2 participants


Back | FazBrowse Home | New Git URL