# Can sleep ever work?
Let's consider the first case, where sleep does not interlock with
advance. In this case, we never know where the other clocks are, which
means it's totally unpredictable what happens when we advance the
timer, unless we really wait some amount of time (how much) to
guarantee they have reached a barrier. It basically requires a
separate barrier so that we know we're stepping the right things.
If we integrate the barrier, we concluded this always led to
deadlock. Why did we conclude that? Our actual real tests immediately
did deadlock when we did this, which is a clue. We're effectively
constructing an n-way barrier where everything must be sleeping. But
what if everything isn't sleeping, what if it's blocked on other
things. In the limit, what if it's blocked on us? What if it doesn't
sleep; if it doesn't sleep then we can't advance.
So, really, we should make the barrier optional. What does that
actually look like? We need to identify a time at the barrier that
everyone begins their sleep, that way they have a predictable wake
time. Then we need the advance to happen.
Going back, the reason fake clocks work well is that the passage of
time within code can generally be considered negligible. As soon as
the code itself measures the passage of time, e.g. via `sleep`, we end
up in knots. We all want to transition together to the next
moment. The old API captured this idea very well. The problem we ran
into is: what if we block on something other than sleep? What if
we're blocked on observing data somewhere? If that happens then we
can't advance the clock and it all just deadlocks (if we're trying to
advance and then upload the data for example).
The sleep API is not a good one to screw with if we do this, because
the application code should be relatively oblivious. So again, an
`advance_rendezvous` type call matches. But then how does this work?
I guess `advance_rendezvous`