poll_readable / poll_writable

[davibe]

Hi. I am using udp_socket to send() and recv() over the same udp socket from different tokio tasks.
https://github.com/mxinden/udp-socket

Such library relies on poll_readable / poll_writable functions.
https://github.com/mxinden/udp-socket/blob/master/src/socket.rs#L71

In my case sends are very slow (~200 ms) and I think its because the recv() task is somehow starving the send task, probably because of this lock https://github.com/smol-rs/async-io/blob/master/src/reactor.rs#L440

I have rewrote the two send() and recv() functions to use the newer .readable() .writable() functions to await readiness, instead of using the poll_ versions and it's working great (sends take < 1ms). However, I fail to understand why exactly. Can somebody help me understand ?

What's the intended usage of poll_* versus .readable() / .writable() ?
What could be wrong with the original implementation ?

Thank you

[notgull]

poll_* based functions are needed to implement the AsyncRead and AsyncWrite traits, as they both need to have poll-based equivalents. The need for these functions will probably subside once AFIT is stabilized in Rust.

[davibe]

Would you be able to elaborate more what may be happening in my usecase and whether it's a good idea to switch to . readable() / .writable() ?

[notgull]

poll_read uses a single slot for the waker that all of the tasks are fighting over. In contrast, each readable future has its own waker slot, which prevents this fighting. This is probably what's slowing down your application. In general Readable is recommended when it's possible.

[davibe]

Am I right thinking that poll_* functions only work correctly in a context that is spawned inside async_io::block_on ?

If i put this anywhere in my code

    let asio = tokio::spawn(async {
        async_io::block_on(async {
            // sleep forever
            sleep_until_or_forever(None).await;
        });
    });

the sends become fast again, but I block one of the tokio threads. I am not grasping what happens yet

[notgull]

A background thread is spawned to handle I/O if block_on isn't called. I would assume that in your case the Tokio threads are pre-empting the async-io thread and preventing it from handling I/O in a timely manner. So, barring reducing the number of threads Tokio uses, explicitly running the reactor like this works (although I would personally do it in a spawn_blocking task).

[davibe]

I think I found a bug in poll_ready(cx). I'll submit an issue / pr