<div id="__MailbirdStyleContent" style="font-size: 10pt;font-family: Arial;color: #000000;text-align: left" dir="ltr">
                                        Hi all --<div><br></div><div>We should watch out to not make Kernel depend on Chronology. So, maybe #busyWait should be in a *Chronology extension then.</div><div><br></div><div>The scenario of simulating some work is interesting. I would do "1 to: 10000 do: [:ea | Object new]" instead.</div><div><br></div><div>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.</div><div><br></div><div>This is a new feature. Not just a bugfix.</div><div><br></div><div>Best,</div><div>Marcel</div><div class="mb_sig"></div>
                                        <blockquote class="history_container" type="cite" style="border-left-style: solid;border-width: 1px;margin-top: 20px;margin-left: 0px;padding-left: 10px;min-width: 500px">
                        <p style="color: #AAAAAA; margin-top: 10px;">Am 02.04.2022 03:15:28 schrieb David T. Lewis <lewis@mail.msen.com>:</p><div style="font-family:Arial,Helvetica,sans-serif">On Mon, Mar 28, 2022 at 10:54:57PM +0200, christoph.thiede@student.hpi.uni-potsdam.de wrote:<br>> =============== Summary ===============<br>> <br>> Change Set:????????fix-busyWait-precision<br>> Date:????????????28 March 2022<br>> Author:????????????Christoph Thiede<br>> <br>> 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:<br>> <br>> ????[1 microSeconds busyWait] bench '6,240,000 per second. 160 nanoseconds per run. 0.67973 % GC time.'<br>> <br>> Moves #busyWait implementation back to Duration and invokes it from Delay. Not sure whether we need the latter hook, though.<br>> <br><br>+1<br><br>This makes sense to me, because when I send #busyWait to a Duration,<br>I expect it to be burning CPU cycles in the context of a process.<br>This seems different from the behavior of a Delay, which wakes up<br>a process after some delay that is evaluated in the "outside world"<br>(the VM and operating system).<br><br>So I prefer the original Chronology-Core-ct.67 approach of letting<br>Duration be responsible for doing a #busyWait.<br><br>Dave<br><br></div></blockquote></div>