On Wed, May 12, 2021 at 8:48 AM Michael Wong via SG14 <sg14_at_[hidden]>
wrote:

> As of the Apr 2021 discussion on low latency general brainstorming chaired
> by Staffan TjernstrÃm , captured in notes here:
> https://lists.isocpp.org/sg14/2021/04/0616.php
>
> This is a summary of that discussion aiming to elicit more refinement,
> leading to possible features:
>
> 1. - issues/problems of the domain in C++
> 1. need to access hardware features, memory card, I/O controller,
> DMA, is low latency an upper bound or determinism
> 2. competing with some OS services but not served by all OS
> 3. C++ can offer standard APIs to query for facility
> 2. - Features/proposals for C++
> 1. thread priorities
> 2. cache-control
> 3. scheduling periodic thread intervals or by the deadline
> 4. CPU pinning like madvise
> 5. manage memory-mapped files
> 6. Vulkan-like capability model that fits specific hardware
> 7. enforce the real-time constraint on a call path or trap at
> runtime if unable to satisfy
>
> Please feel free to add to this discussion with more issues/proposals, and
> more details with possible proposals.
>

Another point (raised in the past by Nial and others) is to recommend that
C++ "standard" APIs (such as those provided through "std::"):

* Prefer APIs that accept memory as-passed-in by the caller, rather than
rely upon internal allocation semantics, or reliance upon allocators.

By defining APIs that demanded already-allocated-memory as parameters, we
could:

(a) better control latency (e.g., the implementation does not even attempt
an allocator-call with possibly variable-length duration)
(b) better leverage hardware-specific resources (e.g., hardware-specific
APIs are leveraged external to the "std::" implementation)

--charley