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

Can we add frame for a function that reutrns Poll<T>? #32

Open
Xuanwo opened this issue Aug 3, 2023 · 6 comments
Open

Can we add frame for a function that reutrns Poll<T>? #32

Xuanwo opened this issue Aug 3, 2023 · 6 comments
Labels
enhancement New feature or request

Comments

@Xuanwo
Copy link

Xuanwo commented Aug 3, 2023

Hi, thanks for creating this lib! OpenDAL is working on for adding native integration with this lib to allow users to dump the async backtrace: apache/opendal#2765.

But we met a problem that we have some trait like AsyncRead returns Poll<T>. Can we add frame for them?

@jswrenn
Copy link
Collaborator

jswrenn commented Sep 20, 2023

Hi @Xuanwo! I apologize for the slow response — I was on an extended leave from work.

I think this is possible. I'll look into it.

@jswrenn jswrenn added the enhancement New feature or request label Sep 20, 2023
@jswrenn
Copy link
Collaborator

jswrenn commented Sep 26, 2023

Can you point me to a type in OpenDAL that implements AsyncRead where you might like to include poll_read in frames?

I think I have a solution that could work for this use-case, but I'd like to be sure.

@Xuanwo
Copy link
Author

Xuanwo commented Sep 27, 2023

Can you point me to a type in OpenDAL that implements AsyncRead where you might like to include poll_read in frames?

Sure!

Here is the code where we added async-backtrace: https://github.com/apache/incubator-opendal/blob/main/core/src/layers/async_backtrace.rs.

Currently, we have only added framed for async functions, and we expect to have them on our Readers just like we do for logging: https://github.com/apache/incubator-opendal/blob/main/core/src/layers/logging.rs#L992-L1037.

We plan to return an AsyncBacktraceWrapper<R> and add frame for it's poll_read, poll_seek functions.

@jswrenn
Copy link
Collaborator

jswrenn commented Sep 28, 2023

I'm experimenting with approaches on the more-frames branch: https://github.com/tokio-rs/async-backtrace/tree/more-frames

I've started by making our Frame type public, which makes it possible to crate your own backtrace frames that aren't in the context of a Future, like so (using tokio's Take as an example):

pin_project! {
    #[must_use = "streams do nothing unless you `.await` or poll them"]
    pub struct Take<R> {
        #[pin]
        inner: R,
        // Add a `Frame` field to your type.
        #[pin]
        frame: async_backtrace::Frame,
        limit: u64,
    }
}

impl<R: AsyncRead> AsyncRead for Take<R> {
    fn poll_read(
        self: Pin<&mut Self>,
        cx: &mut Context<'_>,
        buf: &mut ReadBuf<'_>,
    ) -> Poll<Result<(), std::io::Error>> {
        // And run your async routines `in_scope` of `Frame`.
        let this = self.project();
        this.frame.in_scope(|| {
            unimplemented!("method internals go here")  
        })
    }
}

Does this work for you?

This is fine for AsyncRead (which requires that its receiver is pinned), but I see oio::Read doesn't require a pinned receiver. I'm not yet sure how to support non-pinned frames — pinning is fundamental to how this crate is able to keep track of the structure of futures without allocating.

@Xuanwo
Copy link
Author

Xuanwo commented Oct 7, 2023

I'm experimenting with approaches on the more-frames branch: https://github.com/tokio-rs/async-backtrace/tree/more-frames

Cool! I will give it a try.

This is fine for AsyncRead (which requires that its receiver is pinned), but I see oio::Read doesn't require a pinned receiver.

oio::Read requires to be Unpin so we don't require a pinned receiver.

@Xuanwo
Copy link
Author

Xuanwo commented May 16, 2024

Hi @jswrenn, thanks for your work! This solution works for us. However, we've migrated to an async trait design and no longer need this feature.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants