-
Notifications
You must be signed in to change notification settings - Fork 3.5k
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
GH-41919: [C++][FlightRPC] Avoid using raw pointers for auth handlers #41927
Conversation
Thanks for opening a pull request! If this is not a minor PR. Could you open an issue for this pull request on GitHub? https://github.com/apache/arrow/issues/new/choose Opening GitHub issues ahead of time contributes to the Openness of the Apache Arrow project. Then could you also rename the pull request title in the following format?
or
In the case of PARQUET issues on JIRA the title also supports:
See also: |
|
The AppVeyor github check failure seems unrelated to change:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1
Could you adjust style by pre-commit run -a
?
Done. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks!
That said, this doesn't seem like a guaranteed fix. https://stackoverflow.com/a/47117985/262727 Mutating the shared_ptr while another thread is copying it is still thread-unsafe, just perhaps a little less likely to cause problems than before. I'd still want to at least document the API as thread-unsafe while perhaps allowing this PR to avoid some basic errors |
I didn't think this was a problem but it is. This fix is wrong. |
Closing, since this is the wrong fix: |
Rationale for this change
Avoid pointer access after deletion bug explained in #41919
What changes are included in this PR?
Change SetToken argument from a raw pointer to an
std::shared_ptr
.Are these changes tested?
This PR leans on existing CI tests and compile-time type checking, no additional/specific testing was performed.
Are there any user-facing changes?
No