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

Rust: Safe Api for callbacks #4882

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

youyuanwu
Copy link
Contributor

Description

Use Rust Fn and FnMut for user callback function or closure, so user no longer need to use unsafe extern C function and managing callback context ptr.
Added macro to define common HandleRef type, and set get context functions to reduce code duplication.

Testing

Modified the existing test callbacks to use the new APIs.

Documentation

NA

Copy link

codecov bot commented Mar 3, 2025

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 86.96%. Comparing base (f5f8534) to head (9320b51).
Report is 1 commits behind head on main.

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #4882      +/-   ##
==========================================
- Coverage   87.55%   86.96%   -0.59%     
==========================================
  Files          56       56              
  Lines       17726    17726              
==========================================
- Hits        15520    15416     -104     
- Misses       2206     2310     +104     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@nibanks nibanks added the Language: Rust Related to the Rust interop layer label Mar 3, 2025
) -> Result<(), Status> {
pub fn open<F>(&mut self, registration: &Registration, handler: F) -> Result<(), Status>
where
F: FnMut(ConnectionRef, ConnectionEvent) -> Result<(), Status> + 'static,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Isn't the lifetime of the connection enough here? Callbacks will likely have a context with a limited lifetime.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Callback closure has the lifetime as the handle.
It should be dropped after handle is closed.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right, but isn't 'static here requiring that the handler has a static lifetime? Why not use the lifetime of self?

Copy link
Contributor Author

@youyuanwu youyuanwu Mar 10, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ideally it should be lifetime of self. But Box<ConnectionCallback> cannot be annotated with lifetime so it does not compile. Maybe it is possible somehow or maybe more unsafe trick is needed. It can be a future improvement.

@@ -1423,7 +1561,7 @@ mod tests {
} => {
println!("Stream shutdown complete: {connection_shutdown} {app_close_in_progress} {connection_shutdown_by_app} {connection_closed_remotely} {connection_error_code} {connection_close_status}");
// Attach to stream for auto close handle.
unsafe { Stream::from_raw(stream) };
unsafe { Stream::from_raw(stream.as_raw()) };
Copy link
Contributor Author

@youyuanwu youyuanwu Mar 4, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The only uncertainty I have for this PR is this line.
Ctx is dropped at this line, but the code of execution is inside the callback. This means the current function/closure has already been dropped after this line, and the function has not returned yet. Is this UB?
But naively thinking, after this line if code does not access any closure variables (already dropped), the code is ok. Because the stack is still present, and the remaining function call instruction is just propagating return value to upper stack frame. So far valgrind does not find any memory use problem.
But I still worry this is UB (undefined behaviour).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So, how do we resolve this uncertainty? Can we test it?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The test executes this path and it seems to work, but I think this is UB, the test runs but there is no guarantee from compiler this will work in the future, or under certain optimizations.
We can document that closing handle inside the callback is not safely supported in rust, and user wishing to do so needs to do proper testing for the UB, or use unsafe to extract the ctx and clean it up outside the callback.
In practice closing the handle in the callback might not be a prevalent use case.

@youyuanwu youyuanwu marked this pull request as ready for review March 4, 2025 16:37
@youyuanwu youyuanwu requested a review from a team as a code owner March 4, 2025 16:37
@youyuanwu youyuanwu force-pushed the users/youyuanwu/ffi-fn-callback branch from 75b0dd4 to 6df357d Compare March 6, 2025 19:34
* rebase test to fn branch

* enable server client tests on windows

* enable manual trigger for cargo ci
@@ -804,30 +877,64 @@ impl Default for Connection {
}
}

// Remarks on Rust callback in general:
// Callback function or closure is set to msquic handle context of type `*mut Box<TCallback>>`.
// We cannot use type `*mut TCallback` because dyn trait cannot be converted to a pointer directly.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Issue here being that &dyn Trait is implemented as a 'fat pointer' with a pointer to both the underlying impl along with the vtable for that impl's implementation of the trait. So a single 8 byte pointer won't hold the 16 byte 'fat pointer'

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Language: Rust Related to the Rust interop layer
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants