Stay up-to-date with everything C++!
Content directly fetched from the subreddit just for you.
Join our group for discussions : @programminginc
Powered by : @r_channels
Post #24741
11
([docs](https://fleetcode.com/oss/tmc/docs/v1.4/integration/external_executors.html#fully-integrating)) ([example](https://github.com/tzcnt/tmc-examples/blob/44ce66de8e74107c803645c82ddd88a7be35fd29/examples/external/external_executor.cpp#L68)) specialize `tmc::detail::executor_traits` to integrate an external executor
* ([example](https://github.com/tzcnt/tmc-examples/blob/44ce66de8e74107c803645c82ddd88a7be35fd29/examples/external/callback_awaitable.hpp)) you can even turn a C-style callback API into a TooManyCooks awaitable!
# Designed for Beginners and Experts Alike
TooManyCooks wants to be a library that you'll choose first because it's easy to use, but you won't regret choosing later (because it's also very powerful).
To start, it offers the simplest possible syntax for awaitable operations, and requires almost no boilerplate. To achieve this, sane defaults have been chosen for the most common behavior. However, you can also customize almost everything using fluent APIs, which let you orchestrate complex task graphs across multiple executors with ease.
TooManyCooks attempts to emulate linear types (it expects that most awaitables are awaited exactly once) via a combination of \[\[nodiscard\]\] attributes, rvalue-qualified operations, and debug asserts. This gives you as much feedback as possible at compile time to help you avoid lifetime issues and create correct programs.
There is carefully maintained [documentation](https://www.fleetcode.com/oss/tmc/docs/v1.4/quick_start.html) as well as an extensive suite of [examples and tests](https://github.com/tzcnt/tmc-examples) that offer code samples for you to draw from.
# Q&A
# Is this AI slop? Why haven't I heard of this before?
I've been building in public since 2023 and have invested thousands of man-hours into the project. AI was never used on the project prior to version 1.1. Since then I've used it mostly as a reviewer to help me identify issues. It's been a net positive to the quality of the implementation.
This announcement is well overdue. I could have just "shipped it" many months ago, but I'm a perfectionist and prefer to write code rather than advertise. This has definitely caused me to miss out on "first-mover advantage". However, at this point I'm convinced the project is world-class so I feel compelled to share.
# The name is stupid.
That's not a question, but I'll take it anyway. The name refers to the phrase "too many cooks in the kitchen", which I feel is a good metaphor for all the ways things can go wrong in a multithreaded, asynchronous system. Blocking, mutex contention, cache thrashing, and false sharing can all kill your performance, in the same way as two cooks trying to use the same knife. TooManyCooks's structured concurrency primitives and lock-free internals let you ensure that your cooks get the food out the door on time, even under dynamically changing, complex workloads.
# Will this support Sender/Receiver?
Yes, I plan to make it S/R compatible. It already supports core concepts such as [scheduler affinity](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2025/p3552r3.html#scheduler-affinity) so I expect this will not be a heavy lift.
# Are C++20 coroutines ready for prime time?
In my opinion, there were 4 major blockers to coroutine usability. TooManyCooks offers solutions for all of them:
* Compiler implementation correctness - This is largely solved.
* Library maturity - TooManyCooks aims to solve this.
* HALO - Clang's [attributes](https://clang.llvm.org/docs/AttributeReference.html#coro-await-elidable) are the only implementation that actually works. TooManyCooks fully supports this, and it applies consistently ([docs](https://fleetcode.com/oss/tmc/docs/v1.4/halo/index.html)) ([example](https://github.com/tzcnt/tmc-examples/blob/44ce66de8e74107c803645c82ddd88a7be35fd29/tests/test_halo.cpp)) when the prerequisites are met.
* Debugger integration - LLDB has recently merged support for SyntheticFrameProviders which allow reconstructing the async backtrace in the debugger. GDB also offers a Frame Filter API with similar
* ([example](https://github.com/tzcnt/tmc-examples/blob/44ce66de8e74107c803645c82ddd88a7be35fd29/examples/external/callback_awaitable.hpp)) you can even turn a C-style callback API into a TooManyCooks awaitable!
# Designed for Beginners and Experts Alike
TooManyCooks wants to be a library that you'll choose first because it's easy to use, but you won't regret choosing later (because it's also very powerful).
To start, it offers the simplest possible syntax for awaitable operations, and requires almost no boilerplate. To achieve this, sane defaults have been chosen for the most common behavior. However, you can also customize almost everything using fluent APIs, which let you orchestrate complex task graphs across multiple executors with ease.
TooManyCooks attempts to emulate linear types (it expects that most awaitables are awaited exactly once) via a combination of \[\[nodiscard\]\] attributes, rvalue-qualified operations, and debug asserts. This gives you as much feedback as possible at compile time to help you avoid lifetime issues and create correct programs.
There is carefully maintained [documentation](https://www.fleetcode.com/oss/tmc/docs/v1.4/quick_start.html) as well as an extensive suite of [examples and tests](https://github.com/tzcnt/tmc-examples) that offer code samples for you to draw from.
# Q&A
# Is this AI slop? Why haven't I heard of this before?
I've been building in public since 2023 and have invested thousands of man-hours into the project. AI was never used on the project prior to version 1.1. Since then I've used it mostly as a reviewer to help me identify issues. It's been a net positive to the quality of the implementation.
This announcement is well overdue. I could have just "shipped it" many months ago, but I'm a perfectionist and prefer to write code rather than advertise. This has definitely caused me to miss out on "first-mover advantage". However, at this point I'm convinced the project is world-class so I feel compelled to share.
# The name is stupid.
That's not a question, but I'll take it anyway. The name refers to the phrase "too many cooks in the kitchen", which I feel is a good metaphor for all the ways things can go wrong in a multithreaded, asynchronous system. Blocking, mutex contention, cache thrashing, and false sharing can all kill your performance, in the same way as two cooks trying to use the same knife. TooManyCooks's structured concurrency primitives and lock-free internals let you ensure that your cooks get the food out the door on time, even under dynamically changing, complex workloads.
# Will this support Sender/Receiver?
Yes, I plan to make it S/R compatible. It already supports core concepts such as [scheduler affinity](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2025/p3552r3.html#scheduler-affinity) so I expect this will not be a heavy lift.
# Are C++20 coroutines ready for prime time?
In my opinion, there were 4 major blockers to coroutine usability. TooManyCooks offers solutions for all of them:
* Compiler implementation correctness - This is largely solved.
* Library maturity - TooManyCooks aims to solve this.
* HALO - Clang's [attributes](https://clang.llvm.org/docs/AttributeReference.html#coro-await-elidable) are the only implementation that actually works. TooManyCooks fully supports this, and it applies consistently ([docs](https://fleetcode.com/oss/tmc/docs/v1.4/halo/index.html)) ([example](https://github.com/tzcnt/tmc-examples/blob/44ce66de8e74107c803645c82ddd88a7be35fd29/tests/test_halo.cpp)) when the prerequisites are met.
* Debugger integration - LLDB has recently merged support for SyntheticFrameProviders which allow reconstructing the async backtrace in the debugger. GDB also offers a Frame Filter API with similar
