[squeak-dev] Review Request: fix-busyWait-precision.1.cs
marcel.taeumel at hpi.de
Fri Apr 8 08:09:35 UTC 2022
Hi all --
We should watch out to not make Kernel depend on Chronology. So, maybe #busyWait should be in a *Chronology extension then.
The scenario of simulating some work is interesting. I would do "1 to: 10000 do: [:ea | Object new]" instead.
Please, BE AWARE that if we start to give guarantees below 1 millisecond -- here: 1 nanosecond or 1 microsecond -- we have more maintenance effort in the future.
This is a new feature. Not just a bugfix.
Am 02.04.2022 03:15:28 schrieb David T. Lewis <lewis at mail.msen.com>:
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.
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Squeak-dev