A5rocks

Note while debugging, this `trio.abc.Clock` adapted from `_run.py` seems to work: ```python class SystemClock(trio.abc.Clock): def start_clock(self) -> None: pass def current_time(self) -> float: return time.perf_counter() def deadline_to_sleep_time(self, deadline: float) ->...

I'm fairly certain the root cause is that we don't actually allow `MockClock`-like clocks, so to accomplish it we do some funny things. Specifically, we tightly couple it with the...

Because designing a public API to satisfy all `MockClock`-shaped usages is challenging (especially with n=1 examples to draw from)! Your clock is wrong in that you're using an API (`MockClock`)...

> But I do think that either the attribute setting hack should be fixed, or `abc.Clock` should be marked as private (if indeed the attribute setting is unavoidable), because as...

> It uses the system time _rate_, but `trio.current_time()` still starts from 0. I don't need just real time intervals, I need real absolute dates in production. Ah, sorry, I...

I think I can be a bit clearer. Here's a table where what Trio provides works without workarounds: | in which scenario | auto jump | accurate time | |--------|--------|--------|...

> For that it has to derive from `trio.abc.Clock`, which is currently impossible to implement correctly (using only public API). I'm a bit confused about what you mean here. I...

(for the longest time I assumed this issue was meant for IO too) I think adding a method to wait for readiness on receiving memory channels might solve the need...

Probably by having any implementors implementing a custom `receive()` :^) I guess that's enough argument to not implement it by default using `wait_for_readiness` + `recv_nowait` if it'll be a footgun....

One possible way I guess would be to have `wait_for_readiness` return a ticket which you either `.defer()` (sync) to pass to the next person, or that can be passed (optionally)...