AsyncFdReadyGuard should provide a method to access the inner field of AsyncFd

[yaa110]

Is your feature request related to a problem? Please describe.
Consider implementing AsyncRead for a type that wraps another type which implements std::io::Read and AsRawFd:

// TestIo implements `std::io::Read` and `AsRawFd`.
struct TestIo;

struct Test {
    io: AsyncFd<TestIo>,
}

impl AsyncRead for Test {
    fn poll_read(
        self: Pin<&mut Self>,
        cx: &mut Context<'_>,
        buf: &mut ReadBuf<'_>,
    ) -> task::Poll<io::Result<()>> {
        match self.io.poll_read_ready(cx) {
            Poll::Ready(Ok(guard)) => {
                // Here I need to access `&mut TestIo` (`&mut guard.async_fd.inner`) to `read(...)` from. 
            },
            _ => unimplemented!(),
        }
    }
}

Describe the solution you'd like
AsyncFdReadyGuard should provide access to inner field of its async_fd field. for example:

// A method for `AsyncFdReadyGuard`
pub fn inner_mut(&mut self) -> &mut T {}

Describe alternatives you've considered
Aa an alternative, AsyncFd should implement AsyncRead and AsyncWrite like unexported PollEvented type.

Additional context
PollEvented is not exported in v0.3.x, and AsyncFd was added to provide somewhat similar functionalities (based on changes in mio 0.7.x), however, it lacks some useful implementations.

[Darksonn]

Hmm. The AsyncFdReadyGuard only has an immutable reference to the AsyncFd due to it also being returned by readable and writable.

[bdonlan]

Indeed. We discussed in the original PR the possibility of later defining a AsyncFdReadyGuardMut later for the case where we can get mut access to the object. One question is how often we actually have things like std::io::Read defined, and whether it would be preferable for the underlying object to (where possible) use direct OS calls with a non-mut reference (which would enable use of the futures-oriented interface)

[Sherlock-Holo]

the AsyncFdReadyGuard can't access the inner, and the with_io or with_poll's argument f is only a closure which can't access the inner, so how do I do some IO operation?

[Darksonn]

Currently poll_{read,write}_ready take &self, which is why they can't access the inner variable mutably. There are two options you might make use of to get around this now:

1. Put a raw fd into the AsyncFd and store the object to be mutated next to the AsyncFd.
2. Construct your code to only need &self access to the inner value. This is often possible because all the std types such as File, TcpStream and so on only require &self access to read and write to them.

In the future, we can add an poll_{read,write}_ready_mut method that takes AsyncFd by &mut self and returns an AsyncFdReadyGuardMut, which allows &mut access to the inner value. Alternatively a clear_{read,write} method can be added to allow clearing it after releasing the guard.

[Sherlock-Holo]

@Darksonn Is there any release plan about poll_{read,write}_ready_mut?

[Darksonn]

See #3208.

[Darksonn]

Fixed by #3304.