Just trying io instead of having `poll_read` and `poll_write`? about tokio-core HOT 6 CLOSED

There are other small differences in how tokio and mioco reactor are implemented, and if you think it's worth it, I could dig more into analyzing them and see if anything from mioco could potentially benefit tokio.

BTW. I'm planing to write coroutines as a Future crate (WIP), with mioco-like API, but using tokio IO-types directly, and then phase out mioco completely, and help current users to move their coroutine-based code to tokio ecosystem. That's why I'm investigating tokio reactor design, features and perf.

from tokio-core.

Yes, spurious notifications might be rare. However, note that a single task might be driving many different I/O operations simultaneously. When such a task is awakened, it could very well make many poll_read() or poll_write() calls that return WouldBlock, even as it does make progress on the I/O operation that triggered the wakeup.

Suppose future1 is waiting on udp_socket1.send_to() and future2 is waiting on udp_socket2.send_to(), and these two futures are joined in a single task as future1.join(future2). If udp_socket2 becomes ready, then the task will awakened and the implementation of Join needs to call both future1.poll() and future2.poll() because it has no way of knowing which is actually ready. So in this case, the poll_write() method prevents the task from making a probably-unsuccessful syscall on udp_socket1.

As far as I understand, in the mioco equivalent of join() each branch would be its own userspace thread, receiving its own notifications. This differs from futures-rs, where branch of a join() is still executed in the same task.

from tokio-core.

As @dwrensha said (quite well), it is quite important to avoid syscalls if at all possible and a single task, at the very least, is probably managing both read & write, if not more than one I/O handle.

Hopefully this makes sense, I'm going to close the issue. Feel free to reopen / open a new one if you have more questions.

from tokio-core.

I see. But the each IO has it's own token? So couldn't poll_write test be just if this_io_token == notified_token? That give all the mentioned benefit, while still attempting the syscall only on io that was woken up.

from tokio-core.

@dpc yeah all I/O tokens have their own mio token, but futures then need to understand why they woke up (e.g. what set of tokens caused them to start polling again). That's not possible with the Future::poll interface (no arguments) but is possible with the task::with_unpark_event interface for futures to learn precisely why they woke up.

from tokio-core.

@alexcrichton I'm sorry, I don't understand. One still has token that caused the wakeup, and all Event information, and they still can be passed to the task, I believe.

from tokio-core.