On the Linux platform, does tokio use level-triggered or edge-triggered?

[phil-skillwon]

On the Linux platform, when Tokio uses epoll for I/O multiplexing, does it use level-triggered or edge-triggered? Does the Tokio runtime use epoll for handling file descriptor I/O events, or is there another event detection mechanism employed by the Tokio runtime?

Recently, when I was reading the source code of tokio-serial, I was confused about the loop in the poll_read function. Why is there a loop added in the poll_read/poll_write function? The following code comes from tokio-serial:

#[cfg(unix)]
impl AsyncRead for SerialStream {
    /// Attempts to ready bytes on the serial port.
    ///
    /// Note that on multiple calls to a `poll_*` method in the read direction, only the
    /// `Waker` from the `Context` passed to the most recent call will be scheduled to
    /// receive a wakeup.
    ///
    /// # Return value
    ///
    /// The function returns:
    ///
    /// * `Poll::Pending` if the socket is not ready to read
    /// * `Poll::Ready(Ok(()))` reads data `ReadBuf` if the socket is ready
    /// * `Poll::Ready(Err(e))` if an error is encountered.
    ///
    /// # Errors
    ///
    /// This function may encounter any standard I/O error except `WouldBlock`.
    fn poll_read(
        self: Pin<&mut Self>,
        cx: &mut Context<'_>,
        buf: &mut ReadBuf<'_>,
    ) -> Poll<IoResult<()>> {
        loop {
            let mut guard = ready!(self.inner.poll_read_ready(cx))?;

            match guard.try_io(|inner| inner.get_ref().read(buf.initialize_unfilled())) {
                Ok(Ok(bytes_read)) => {
                    buf.advance(bytes_read);
                    return Poll::Ready(Ok(()));
                }
                Ok(Err(err)) => {
                    return Poll::Ready(Err(err));
                }
                Err(_would_block) => continue,
            }
        }
    }
}

[NobodyXu]

IMO tokio (and tokio-uring) should be edge triggered, the loop is needed because the fd might be read concurrently

[phil-skillwon]

@NobodyXu
Could you please explain in more detail the viewpoint that 'the loop is needed because the fd might be read concurrently'?

My understanding of adding the loop is that when the fd is ready for reading, immediately calling read does not necessarily guarantee that data can be read. The read operation might return WOULDBLOCK, in which case it is necessary to try polling the fd again and retrying the read operation.

[NobodyXu]

Yeah that's also my understanding, my thought is that some other threads/processes could consume all the data before this read so a loop is needed.