On Wed Oct 21, 2026 at 1:05 PM JST, John Hubbard wrote:
> On 10/20/26 8:23 PM, Eliot Courtney wrote:
>> On Wed Oct 21, 2026 at 12:12 PM JST, John Hubbard wrote:
>>> On 10/20/26 7:57 PM, Eliot Courtney wrote:
>>>> On Tue Oct 20, 2026 at 11:27 PM JST, Alexandre Courbot wrote:
>>>>> On Tue Oct 20, 2026 at 7:18 PM JST, sashiko-bot wrote:
>>>> [...]
>>>> I'm also fine with special casing `wait_for_msg`, but personally
>>>> (maybe) sleeping when you set timeout to Delta::ZERO sounds busted to
>>>> me.
>>>
>>> It's not necessarily wrong, depending on how you think about it:
>>> "sleep, but timeout at zero" is something I've seen used (I forget
>>> where) as to mean "context switch away", kind of like a cpu_relax().
>>
>> Here, it only sometimes sleeps ("(maybe)"), depending on the resolution
>> of the timer and how long stuff takes. So it's really pretty
>> inconsistent IMO.
>
> Yes it is going to act in ways that look non-deterministic. And that's
> OK, because:
>
> a) It's not broken.
>
> b) It's not unreasonable nor even terribly surprising behavior: one
> can reason about it.
>
> c) The requested behavior itself is impossible: "do X for an infinitely
> short amount of time".
>
> Why are we adding code to optimize behavior for callers that should
> not even exist?
>
> thanks,
Yerp you convinced me. I also realised that we can't just change
`start.elapsed() > timeout_delta` to `start.elapsed() >= timeout_delta`
because it could end up not waiting enough time (due to integer stuff).
