<story><title>Time is not a synchronization primitive</title><url>https://xeiaso.net/blog/nosleep</url></story><parent_chain></parent_chain><comment><author>pmontra</author><text>I agree that it is no synchronization primitive and that even if it was, it&amp;#x27;s very fragile. However I found it in nearly every project I worked on, in backend tests, frontend tests and even in integration tests where the library driving the browser should take care of waiting for elements to appear on screen. Modals and browser dialogs are particularly good at breaking stuff.&lt;p&gt;The dynamic is: developers write the the test and it usually works on their machines. If it does not there is a chance that they figure out what&amp;#x27;s wrong and  rewrite it in the proper way. Tests often work locally, where the CPU and disk are nearly 100% available to run them. Sometimes they fail on CI systems. Developers scratch their heads and attempt the easy fix of adding a sleep of 1 second. That almosts always work and it took 5 minutes, code, commit, test run. They know that it stinks but they have stuff to do. Every few months somebody attempts to remove some of those sleeps with mixed and often unsuccessful results. Integration tests are particularly nasty.</text></comment>
<story><title>Time is not a synchronization primitive</title><url>https://xeiaso.net/blog/nosleep</url></story><parent_chain></parent_chain><comment><author>hayley-patton</author><text>Did a devops elective last semester; I was surprised to hear that sleeping to wait for the system to come up was &amp;quot;common in the industry&amp;quot;. 30 seconds was the magic number, which was somehow always either mostly a waste or not enough when I tried to use it.&lt;p&gt;For similar reasons, we similarly can&amp;#x27;t keep making sleep-sort faster by scaling the sleeps down.</text></comment>