I’m guessing the timing on the Cancel tokens described here won’t be perfectly exact - it’ll take some (small) amount of time to call after, such that time.monotonic is slightly late.
Assuming that’s the case, would this timing error compound with repeated calls to after?
If not, why?, and if so, could the Cancel token structure be changed to fix this?
I’m guessing this isn’t super important for most of trio’s applications, but I was curious about it anyway - I’ve seen a similar construct in Ada where non-compounding timing errors matter a lot.