I had the idea to abuse the address of reactor"s Inner as the Id. But it doesn"t seem to work ‒ as the remote uses it to check against currently running loop, the comparison might return a false positive (eg. if the loop and all the handles pointing to it went away, the memory got freed and a new one could have been allocated at its place).

However, would it be acceptable to use Arc instead of Rc and store it"s Weak inside the Remote? That way the Remote would keep the memory allocated until it died (because its counter must be in the same chunk of memory as the data it points to, as Arc promises only a single allocation) and no reuse could happen.

We currently document a guarantee that ids are globally unique, and addresses would allow for recycling, so we may not be able to base this off an address.

Was the documentation change actually released? Furthermore, tokio-core"s interface is said to not be stable yet anyway, so it could be decided the guarantee relaxation is OK…

The problem of never reusing the IDs is that they either can run out or need to be growing in size over time and neither is very nice. But maybe using 64bit numbers makes the problem of running out an academic problem (to run out in 10 years of runtime of the program, it would have to construct 58494241735 new loops every second, if I count correctly).

It"s been released, yes, but I feel like worry about the maximum number of loops for the lifetime of a process is a purely theoretical problem. No practical program will ever exhaust the 64-bit space and we can easily add a 64-bit counter (or larger) behind a global lock.