<p>Most programming languages such as <a href="https://stackoverflow.com/a/377463/16217248">Python</a> and <a href="https://stackoverflow.com/a/9747668/16217248">C++ but only after 2011</a> have some way of initiating a time delay for a fixed amount of real time. C lacks any of such facilities and C++ lacked them until 2011 which is relatively recently considering C++ was from the 80s.</p>
<p>Is there more to adding timing capabilities them that one would first expect? What are the limitations that prevents some languages from adding them? I would expect any architecture to have the capability to access a real-time clock, so what does one give up by mandating support for timing functions?</p>

<standard-library>
What limitations are there to adding timing functions to a standard library?
CC BY-SA 4.0
2023-07-01T18:48:17.040Z
C does [have sleep](https://www.geeksforgeeks.org/sleep-function-in-c/) but only in platform specific headers. It functions basically the same on every platform though so it seems the only reason it wasn't standardizes is that nobody standardized it when the standard library was defined. (Now answering since I am unsure)
mousetail 'he-him'
<p>Sleeping prototypically blocks a thread, which isn’t always preferable. Swift (and no other language that I’m aware of) circumvents this by making <a href="https://developer.apple.com/documentation/swift/task/sleep(nanoseconds:)" rel="noreferrer">its <code>sleep</code> function</a> async. It schedules the rest of the task to be completed after that much time, and throws a <code>CancellationError</code> if the task is cancelled before that happens.</p>

CC BY-SA 4.0
2023-07-01T18:59:49.003Z
2023-07-01T18:59:49.003Z
Bbrk24
<p>Portability is one problem. Different systems might:</p>
<ul>
<li>Support different timing precisions (seconds, milliseconds, microseconds, nanoseconds, etc.)</li>
<li>Have different behavior regarding interrupts (e.g., <code>sleep</code> can be interrupted on POSIX due to things other than the specified time being reached, necessitating <code>sleep</code>ing again)</li>
<li>Differ on whether sleeping for zero seconds is allowed, and how that behaves</li>
</ul>
<p>With some work one could hide most of these differences from the caller, but this does necessitate some extra work, and any inconsistencies that can't be fixed (e.g., nanosecond precision support) would need to be documented and handled in a reasonable manner.</p>

CC BY-SA 4.0
2023-07-01T19:10:02.077Z
2023-07-01T19:10:02.077Z
rydwolf
<p>One good reason can be to not give the users a false hope that the requested delay will actually be honoured at any meaningful precision (and if we're talking about any typical OS, there is a guarantee it won't).</p>
<p>If the users are interested in an actual real-time delay, they must do it on their own in a platform/problem specific way, and it is not going to be easy or portable. Sad reality, but it is better respected and acknowledged.</p>

CC BY-SA 4.0
2023-07-02T08:15:33.403Z
2023-07-02T08:15:33.403Z
SK-logic
# What limitations are there to adding timing functions to a standard library?
Posted by: username_0 on 2023-07-01
Most programming languages such as [Python](https://stackoverflow.com/a/377463/16217248) and [C++ but only after 2011](https://stackoverflow.com/a/9747668/16217248) have some way of initiating a time delay for a fixed amount of real time. C lacks any of such facilities and C++ lacked them until 2011 which is relatively recently considering C++ was from the 80s.

Is there more to adding timing capabilities them that one would first expect? What are the limitations that prevents some languages from adding them? I would expect any architecture to have the capability to access a real-time clock, so what does one give up by mandating support for timing functions?
**Tags:** standard-library
> **Comments:**
> **username_1**: C does [have sleep](https://www.geeksforgeeks.org/sleep-function-in-c/) but only in platform specific headers. It functions basically the same on every platform though so it seems the only reason it wasn't standardizes is that nobody standardized it when the standard library was defined. (Now answering since I am unsure)  
---
## 3 answers
### Answer by username_2 on 2023-07-01. Score: 5
Sleeping prototypically blocks a thread, which isn’t always preferable. Swift (and no other language that I’m aware of) circumvents this by making [its `sleep` function](https://developer.apple.com/documentation/swift/task/sleep(nanoseconds:)) async. It schedules the rest of the task to be completed after that much time, and throws a `CancellationError` if the task is cancelled before that happens.
---
### Answer by username_3 on 2023-07-01. Score: 5
Portability is one problem. Different systems might:

* Support different timing precisions (seconds, milliseconds, microseconds, nanoseconds, etc.)
* Have different behavior regarding interrupts (e.g., `sleep` can be interrupted on POSIX due to things other than the specified time being reached, necessitating `sleep`ing again)
* Differ on whether sleeping for zero seconds is allowed, and how that behaves

With some work one could hide most of these differences from the caller, but this does necessitate some extra work, and any inconsistencies that can't be fixed (e.g., nanosecond precision support) would need to be documented and handled in a reasonable manner.
---
### Answer by username_4 on 2023-07-02. Score: 2
One good reason can be to not give the users a false hope that the requested delay will actually be honoured at any meaningful precision (and if we're talking about any typical OS, there is a guarantee it won't).

If the users are interested in an actual real-time delay, they must do it on their own in a platform/problem specific way, and it is not going to be easy or portable. Sad reality, but it is better respected and acknowledged.
---
