A new version of Chronology-Core was added to project The Inbox:
http://source.squeak.org/inbox/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!