Hi Christoph, Marcel,

On 4/1/22 11:52, christoph.thiede at student.hpi.uni-potsdam.de wrote:
> Hi Marcel,
> 
> thanks for the critique.
> 
> For reference, normal #wait also does not wait long enough for small durations:
> 
> 	[1 microSecond wait] bench '1,440,000 per second. 696 nanoseconds per run. 12.2 % GC time.' 
> 
> Then again, one of my main scenarios when I proposed the original version of #busyWait was exactly to program precise tiny delays. I used this to simulate any kind of - more or less expensive - computations in order to test progress bars and other status updates (for example, conversations filters in SIT). So, my #unknownCompute method will be called thousands or ten-thousands of times and I want to simulate that each computation takes about 10 microSeconds. Isn't this a fair scenario to you? :-)
+1

You need quite precise delays when reading from certain hardware devices
and real-time data streams.  This is in addition to using it to simulate
a very fast yet-unwritten method to ensure your program can keep up and
not blow up the input buffer or starve the output buffer.

I feel supporting precision timekeeping would really open up Squeak's
potential users to people who are stuck using some less ideal language
(C family, Ada) because it can handle real-time streamed data and Squeak
can't.