tokio | A runtime for writing reliable asynchronous applications

Currently the only way to do it is to make self last arbitrarily long through the use of Arc. Since run() is a method on UdpServer, it requires the change to Arc, which you considered but rejected because it felt worse. Still, that's the way to do it:

Rust currently does not provide an async runtime in the standard library. For full details, see Asynchronous Programming in Rust, and particularly the chapter on "The Async Ecosystem."

Rust currently provides only the bare essentials for writing async code. Importantly, executors, tasks, reactors, combinators, and low-level I/O futures and traits are not yet provided in the standard library. In the meantime, community-provided async ecosystems fill in these gaps.

Rust has very strict backward compatibility requirements, and they haven't chosen to lock-in a specific runtime. There are reasons to pick one over another (features versus size for example), and making it part of the standard library would impose certain choices that aren't clearly the right ones for all projects. This may change in the future as the community projects better explore this space and help determine the best mix of choices without the strong backward compatibility promises.

You need to add some sync mechanism so the access to the vector is controlled. An Arc<_>>> would do:

#[main] is an old, unstable attribute that was mostly removed from the language in 1.53.0. However, the removal missed one line, with the result you see: the attribute had no effect, but it could be used on stable Rust without an error, and conflicted with imported attributes named main. This was a bug, not intended behaviour. It has been fixed as of nightly-2022-02-10 and 1.59.0-beta.8. Your example with use tokio::main; and #[main] can now run without error.

Before it was removed, the unstable #[main] was used to specify the entry point of a program. Alex Crichton described the behaviour of it and related attributes in a 2016 comment on GitHub:

Ah yes, we've got three entry points. I.. think this is how they work:

• First, #[start], the receiver of int argc and char **argv. This is literally the symbol main (or what is called by that symbol generated in the compiler).
• Next, there's #[lang = "start"]. If no #[start] exists in the crate graph then the compiler generates a main function that calls this. This functions receives argc/argv along with a third argument that is a function pointer to the #[main] function (defined below). Importantly, #[lang = "start"] can be located in a library. For example it's located in the standard library (libstd).
• Finally, #[main], the main function for an executable. This is passed no arguments and is called by #[lang = "start"] (if it decides to). The standard library uses this to initialize itself and then call the Rust program. This, if not specified, defaults to fn main at the top.

So to answer your question, this isn't the same as #[start]. To answer your other (possibly not yet asked) question, yes we have too many entry points.

If you switch to

While you can't return an impl Future from an impl FnMut, you can return a boxed future, i.e. a dyn Future which must be boxed because it's in return position. After a bit of borrow checker tetris, we arrive to this:

The error is explicit:

the trait Reply is not implemented for ()

The problem is that your stats endpoint do not return anything, just remove the last ; so it gets returned as the last expresion in the closure:

When you specify 'a as a generic parameter, you mean "I premit the caller to choose any lifetime it wants". The caller may as well choose 'static, for example. Then you promise to pass &'a mut i32, that is, &'static mut i32. But i does not live for 'static! That's the reason for the first error.

The second error is because you're promising you're borrowing i mutably for 'a. But again, 'a may as well cover the entire function, even after you discarded the result! The caller may choose 'static, for example, then store the reference in a global variable. If you use i after, you use it while it is mutably borrowed. BOOM!

What you want is not to let the caller choose the lifetime, but instead to say "I'm passing you a reference with some lifetime 'a, and I want you to give me back a future with the same lifetime". What we use to achieve the effect of "I'm giving you some lifetime, but let me choose which" is called HRTB (Higher-Kinded Trait Bounds).

If you only wanted to return a specific type, not a generic type, it would look like:

First of all, handler is not callable, it's a member struct of Client_v2. You need to access it through the dot operator: self.handler.handle().

On to the actual question:

Runtime::spawn requires the provided future to be 'static + Send, i.e., it can't borrow data and it must be possible to move it to another thread.

The 'static requirement is due to the parent thread possibly exiting before the thread executing the future, thus any data given to the task must be ensured to live at least as long as the task itself.

It must be Sendable because the tokio runtime is free to move spawned Futures between the threads of its threadpool.

The relevant requirement for your error is the first one, the future produced by Handler::handle is not 'static because the function borrows self as a shared reference: async fn handle(&self). Calling this function produces a Future + 'a where 'a is the lifetime of &'a self, i.e. you could write the whole signature as fn handle<'a>(&'a self) -> impl Future + 'a + Send but Runtime::spawn needs you to return impl Future + 'static + Send.

To prove that you're not borrowing data from &self in handle, you can use an async {} block and explicitly state the return type as impl Future + Send + 'static: