If the value is Copy that value will continue to be usable after the runtime has been stopped and dropped, defeating the purpose.
If the value borrows from the runtime to prevent that, futures that hold on to that value stop being `'static`, which brings its own problems, chief among them being breaking `tokio::spawn()` and causing a self-reference (runtime contains futures which contain borrows of itself).
If the value holds on to (a refcount of) the runtime internally to prevent the runtime from being dropped until the value has been dropped, that will prevent programs from exiting as long as even one future is still running on the runtime, which is undesirable.
You don’t actually need it to be a reference; the runtime could generate a random int64 and then pass that around as a “runtime id” which could be checked when used.
You’re correct that my proposal doesn’t solve every problem with Tokio. I hope someone more knowledgeable than me can write a proposal that solves all the problems.
Checked where? In global mutable state you mentioned that has to be created beforehand in the same way you mention? I don't really see how this changes much other than making everything more verbose from the extra argument.
It would be nice for someone to come to with a new solution to solve everything, but I don't think it's as simple as just "use an id and then tidy up some remaining details". No one has come up with something more compelling yet because those details are where the fundamentally are part of the problem is. When the hard problem is figuring out semantics that will allow exposing a better API, proposing an API and then hoping someone finds a way to make it work under the hood is just backwards.
The verbosity is the point! I want functions that interact with a specific expectation of global state to clearly mark that in their type, and the least complicated way to do that is my proposal. I hope someone can invent something more compelling, but my proposal is still an improvement of the status quo.
I think the toplevel commenter was looking for something that could be checked at compile time. The "random int64" idea is identical to "some type that implements Copy", and would require runtime verification, which is not really an improvement on the current state of affairs.
It would prevent callers from not knowing the function depends on a specific runtime. That’s a huge improvement in my opinion.
I expect something along the lines of the GhostCell paper could be used to implement this, to be honest, but I think it would be more verbose than necessary.
(Really, we need an effects system, and then Tokio could just be an effect that contains, but is different from, async)
Does anyone realistically shut down the Tokio runtime once it's been started? It wouldn't be a problem if the runtime is immortal once created; the runtime reference becomes more of a token demonstrating that, yes, this is running under Tokio.
Though I don't think this is such a huge problem. Yes, it's a runtime crash that could potentially be eliminated at compile-time, but realistically that will only happen once during development, and it will be an easy fix.
If I'm writing an async program (that is, with an async main()), then no, I'll never be shutting my runtime down.
But if I already have a non-async program, but need to use an async library, then yes, I'll probably spin up the runtime before using the library, and shut it down after I'm done using it. Unless of course I expect to be using that library for the full run-time of my program, in which case it'll exist for the duration.
> I'll probably spin up the runtime before using the library, and shut it down after I'm done using it.
Hopefully the library did not leave any background tasks running that you can't ask it to stop :) Raymond Chen has a lot of enlightening horror stories about multi-threaded COM (and multi-threaded programming in general) on his blog that are applicable not only to Windows, but in general context as well.
If the value borrows from the runtime to prevent that, futures that hold on to that value stop being `'static`, which brings its own problems, chief among them being breaking `tokio::spawn()` and causing a self-reference (runtime contains futures which contain borrows of itself).
If the value holds on to (a refcount of) the runtime internally to prevent the runtime from being dropped until the value has been dropped, that will prevent programs from exiting as long as even one future is still running on the runtime, which is undesirable.