What does tokio provide over mini-tokio?

[anon80458984]

1. mini-tokio has blazingly fast compile time

2. tokio compile time is not so fast

Practically speaking, what is it that tokio offers over mini-tokio ? I am seriously considering, for tasks where I need lightweight async, to just use mini-tokio instead.

[alice]

Well, for one it provides an IO and time driver. You can't make any kind of async IO in mini-tokio.

Have you considered disabling features of Tokio you don't need? This can help quite a lot - especially the macros feature.

[anon80458984]

@alice

You can't make any kind of async IO in mini-tokio.

Could you expand on this more? The two cases I have in mind for using mini-tokio are:

1. async_io via io_uring: rio - Rust

2. handling tcp connections

in both situations, I have the "problem" that a read may only return N bytes, shorter than the full length of the expected message; I would write some 'accumulator' state machine to keep track of this ... or just using async/await would make things much cleaner

I don't know if this proves or disproves your point -- I am precisely using mini-tokio for async io ... but I am "building all the plumbing" myself

[alice]

I mean, in that case it sounds like you're using a separate standalone IO driver.

[Yandros]

Ok, for context, since there is no mini-tokio crate or whatnot, this is referring to a basic executor example written for pedagogic purposes, over the Tokio website:

Async in depth | Tokio - An asynchronous Rust runtime

• This, in turn, links to the following repo

---

Now, to remain in the flavour of minimal/basic executors (but no reactors ! e.g., neither timers nor I/O), there is also:

pollster

extreme

smol

And ::futures::executor::{self, block_on} as well, of course. This one is to be seriously considered because the futures dependency is almost always around / available, but IIRC, the implementation of the executor, in and of itself, is not as simple as the aforementioned ones.

---

And, on the other end of the spectrum, a mini-reactor for TCP connections (built atop mio, so the platform-specific nitty-gritty details (e.g., syscalls) lie therein):

kprotty/yaar/blob/49e44cd86c69be046acedd5f28847624a836f913/src/net.rs

[alice]

One problem with mini-tokio is that extra wakeups puts the task in the queue multiple times.

[Yandros]

Could that then lead to a panic, or is there some fuse-ing implemented (haven't looked at the details of mini-tokio, so sorry if the answer is obvious there)?

[alice]

Maybe, not sure.

Yes, it can lead to panics due to polls after completion.

[alice]

But back to the question of compile times: Did you try compiling Tokio after disabling most of the features besides rt? It should compile much faster.

[anon80458984]

@Yandros

And ::futures::executor::{self, block_on} as well, of course. This one is to be seriously considered because the futures dependency is almost always around / available, but IIRC, the implementation of the executor, in and of itself, is not as simple as the aforementioned ones.

This is the answer to the question I did not mask but should have asked. There is also an even more lightweight version: future_lite: futures_lite - Rust

@alice

But back to the question of compile times: Did you try compiling Tokio after disabling most of the features besides rt ? It should compile much faster.

I think you have asked me this before. There was some reason it did not work out, but I cam not remember the reason.

[NikosEfthias]

@anon80458984

in both situations, I have the "problem" that a read may only return N bytes, shorter than the full length of the expected message; I would write some 'accumulator' state machine to keep track of this ... or just using async/await would make things much cleaner

AsyncReadExt trait has a read_exact method that will try to fill the buffer you give or die trying. That can solve your issue without really involving any state machine. Also, buffer methods are really great if you don't want to deal with the cursor counting by yourself