On Mon, Mar 28, 2022 at 10:54:57PM +0200, christoph.thiede at student.hpi.uni-potsdam.de wrote:
> =============== Summary ===============
> 
> Change Set:????????fix-busyWait-precision
> Date:????????????28 March 2022
> Author:????????????Christoph Thiede
> 
> Fixes #busyWait for durations < 1 milliSecond. Since the original proposal (Chronology-Core-ct.67), the implementation had been moved from Duration to Delay (Chronology-Core-mt.71). However, Delay has only milliseconds precision, causing shorter durations to be handled as a delayDuration of 0 milliSeconds and leading to this erroneous output:
> 
> ????[1 microSeconds busyWait] bench '6,240,000 per second. 160 nanoseconds per run. 0.67973 % GC time.'
> 
> Moves #busyWait implementation back to Duration and invokes it from Delay. Not sure whether we need the latter hook, though.
> 

+1

This makes sense to me, because when I send #busyWait to a Duration,
I expect it to be burning CPU cycles in the context of a process.
This seems different from the behavior of a Delay, which wakes up
a process after some delay that is evaluated in the "outside world"
(the VM and operating system).

So I prefer the original Chronology-Core-ct.67 approach of letting
Duration be responsible for doing a #busyWait.

Dave