Marcel Taeumel uploaded a new version of Chronology-Core to project The Trunk: http://source.squeak.org/trunk/Chronology-Core-ct.67.mcz
==================== Summary ====================
Name: Chronology-Core-ct.67 Author: ct Time: 2 July 2021, 6:11:19.127885 pm UUID: 7a3d4136-ddb1-ea49-a035-d166391d3fb1 Ancestors: Chronology-Core-dtl.66
Adds Duration >> #busyWait and some explaining prose.
See http://lists.squeakfoundation.org/pipermail/squeak-dev/2021-July/215928.html. Thank you for the feedback!
=============== Diff against Chronology-Core-dtl.66 ===============
Item was added: + ----- Method: Duration>>busyWait (in category 'squeak protocol') ----- + busyWait + "Run an infinite loop until the receiver has elapsed. Performance-intensive!! Usually, you will want to use #wait instead which does not stress the interpreter but instead uses a delay, giving other processes the chance to run. However, scheduling a Delay comes with a synchronization overhead which denies its suitability for very short or precise delays. See http://lists.squeakfoundation.org/pipermail/squeak-dev/2021-July/215928.html for further information." + + "[3 seconds busyWait] timeToRun" + + | proceedTime | + proceedTime := Time utcMicrosecondClock + self asMicroSeconds. + [Time utcMicrosecondClock >= proceedTime] whileFalse!
Item was changed: ----- Method: Duration>>wait (in category 'squeak protocol') ----- wait + "Convert this duration in a delay and wait once. Answer the created delay so that the client can wait on it again if needed. While this is the most CPU-friendly implementation, it comes with a small overhead for scheduling the delay as scheduling must be synchronized over all processes (see Delay >> #schedule). For very short, precise delays, consider using #busyWait instead." - "Convert this duration in a delay and wait once. Answer the created delay so that the client can wait on it again if needed." "[3 seconds wait] timeToRun" ^self asDelay wait!