15 ms·

So the solution is to have a thread waiting on the future. Technically you'd need a thread per future, which is not exactly scalable. The article uses a pool wh

So the solution is to have a thread waiting on the future. Technically you'd need a thread per future, which is not exactly scalable. The article uses a pool which has its own problems. The article even mentions an arguably better approach (check on a timer), but for some reasons claims it is worse. Those integrations are not exactly good designs regardless; simply don't use std::future is the solution, and use non-blocking async mechanisms that can cooperate on the same thread instead. Standard C++ has one albeit somewhat overcomplicated, senders and receivers. Asio also works.

gpderetta 1y ago
Boost also has a better future that at least allows composition. But yes, do not use std::future except for the most simple tasks.
- Davidbrcz 1y ago
  I work with C++, but the amount of don't use standard feature X because reason' is crazy.
  - account42 1y ago
    It is a bit sad to see this for newer features. Maybe the committee should re-evaluate how quickly new designs are pushed into the standard and allow for a bit more time for evaluation. Moving fast makes sense when it's ok to break thinks, not so much when you need to support the result forever.
    - m-schuetz 1y ago
      On the contrary, I think they should move faster and provide more convenience functions that are "good enough" for 90% of use cases. For power users, there will always be a library that addresses domain-specific issues better than the standard could ever hope to. Instead, the comitee attempts to work towards perfect solutions that don't exist, and ends up releasing overengineered stuff that is neither the most convenient, performant, nor efficient solution. Like <random>
      - pjmlp 1y ago
        And who gets to implement those ideas faster, many of which were never implemented before being added into the standard in first place? The surviving three compilers are already lagging as it is, none of them is fully 100% C++20 compliant, C++23 might only become 100% on two of them, lets see how C++26 compliance turns out to be, meanwhile C++17 parallel algorithms are only fully available in one of them, while the two other ones require TBB and libstdc++ to actually make use of them.
        m-schuetz 1y ago
        I'm obviously not talking about modules-level features that may never get to see the light of day. A random(min, max) function isn't rocket science and already a major inprovement over the three-liner that is currently necessary. The major compiler devs won't take long to implement these cases, just as it did not take them long to implement simple yet useful functionality in previous versions of the standard. And the standard library is full with these cases of missing convenience functions over deliberately over-engineered functions.
        pjmlp 1y ago
        Modules have already seen the light of day in VC++ and clang. Anyone using a recent version of Office, is using code that was written with C++20 modules. It is relatively easy to see how far behind compiler developers are regarding even basic features. Note that two of the three major surviving compilers are open source projects, and in all three major compilers, the big names have ramped down their contributions, as they rather invest into their own languages, seeing the current versions as good enough for existing codebases.
      - account42 1y ago
        Well designed functions that deliberately target only 90% of use cases are fine. Badly designed library types that end up being effectively deprecated but you still need to deal with for decades because they end up in all kinds of interfaces are not.
    - Davidbrcz 1y ago
      I wouldn't mind if they actually _fix_ features afterward, even if it means breaking change.
      - account42 1y ago
        Users would mind though. Strong backwards compatibility is a very useful feature even if it does mean that you need to be careful about new additions.
    - lenkite 1y ago
      C++ really needs a fast-deprecate and kick out strategy for features that have proven to be poor - whether by bad design or bad implementation. And compilers should auto warn about such features.
    - pjmlp 1y ago
      Although C++ is one of my favourite languages, I feel the current WG21 process is broken, it is one of the few language evolution processes where proposals are allowed to be voted in without any kind of preview implementation for community feedback, or even to actually validate the idea. I have to acknowledge that none of the other ISO languages, including C, are this radical. That is how we are getting so much warts of lately. Unfortunelly there doesn't seem to exist any willingness to change this, until it will be too late to matter.
      - mgaunard 1y ago
        that's not true, implementations are more often required than not
    - gpderetta 1y ago
      std::future was caught in coroutine/network/concurrency/parallelism master plan that has been redesigned way too many times. Sender/Receivers is the the current direction, and while I don't dislike it, we are still far for a final design to cover all use cases (we still don't have a sender/receiver network library proposal I think). Whatever we end up with, std::future just wasn't a good base for an high performance async story. Still just adding a readiness callback to std::future would make it infinitely more useful even if suboptimal. At least it would be usable where performance is not a concern.
      - mgaunard 1y ago
        There is such a proposal
        gpderetta 1y ago
        A recent one? Do you remember the doc number? edit: if you mean the concurrency TS, I think that's dead right?
        mgaunard 1y ago
        http://wg21.link/P2762 http://wg21.link/P2762
meindnoch 1y ago
>The article even mentions an arguably better approach (check on a timer), but for some reasons claims it is worse. How do you know what timeout to use for the timer? You may end up with tons of unnecessary polling if your timeout is too short, or high latency if your timeout is too long. >Standard C++ has one albeit somewhat overcomplicated, senders and receivers *in C++26
- pjmlp 1y ago
  Or CUDA, which is getting its own compute version.
- mgaunard 1y ago
  > how do you know what timeout to use? adjust based on your minimum expected latency, potentially with exponential backoff. Potentially account for scheduler overhead of the spurious wake-ups. Basically if you check every millisecond to every 10ms, you should be fine. > in C++26 it's a library, language support is not necessary. There are implementations you can use right now.
OskarS 1y ago
I think the idea is that you're using some external library (e.g. database drivers) which do not use asio but returns a std::future. You can't just "not use std::future" if that's what your library uses without fully rewriting your external library. The other option is as you mention polling using a timer, but I don't see how that's better, I'd rather move the work off of the event loop to a thread. And you then have to do the "latency vs. CPU time" tradeoff dance, trying to judge how often to poll vs. how much latency you're willing to accept.
- mgaunard 1y ago
  I'd argue using third-party libraries in a C++ project is a bad idea to begin with. Bad ones especially.
benreesman 1y ago
An imperfect but really useful standard for whether or not a C++ feature is going to work out is how long and troublesome the standardization process is. Modules? Never happening boys, the time has passed when anyone cares. Coroutines? Break gdb forever? Keep dreaming. Look at what they can do when it's clearly a good idea and has the backing of the absolute apex predator experts: reflection. If reflection can fucking sail through and your thing struggles, it's not going to make it. Andrew Kelley just proposed the first plausible IO monad for a systems language, and if I wanted to stay relevant in async C++ innovation I'd just go copy it. Maybe invert the life/unlift direction. The coroutines TS is heavily influenced by folly coroutines (or vice versa), a thing with which I have spent many a late night debugging segfaults. Not happening. Besides, if threads are too slow or big now? Then everything but liburing is.
- cherryteastain 1y ago
  Coroutines are well supported in boost::asio and are deployed in production in more places than you would think.
  - benreesman 1y ago
    A second heuristic for things that aren't going to work out well is stuff that came from Boost. Oh sure, there was a time back in the TR11 days when it was practically part of the standard. But if it's on anyone's "cool, we'll link that, no problem" list in 2025? I don't know them.
    - spacechild1 1y ago
      Asio is actually independent from boost and it is by far the most popular C++ networking library.
- pjmlp 1y ago
  Not everyone is using C++ on Linux with GCC. There are people where modules and co-routines already happened, and there is better debugging experiences out there than gdb.

gpderetta 1y ago

Boost also has a better future that at least allows composition. But yes, do not use std::future except for the most simple tasks.

Davidbrcz 1y ago
I work with C++, but the amount of don't use standard feature X because reason' is crazy.
- account42 1y ago
  It is a bit sad to see this for newer features. Maybe the committee should re-evaluate how quickly new designs are pushed into the standard and allow for a bit more time for evaluation. Moving fast makes sense when it's ok to break thinks, not so much when you need to support the result forever.
  - m-schuetz 1y ago
    On the contrary, I think they should move faster and provide more convenience functions that are "good enough" for 90% of use cases. For power users, there will always be a library that addresses domain-specific issues better than the standard could ever hope to. Instead, the comitee attempts to work towards perfect solutions that don't exist, and ends up releasing overengineered stuff that is neither the most convenient, performant, nor efficient solution. Like <random>
    - pjmlp 1y ago
      And who gets to implement those ideas faster, many of which were never implemented before being added into the standard in first place? The surviving three compilers are already lagging as it is, none of them is fully 100% C++20 compliant, C++23 might only become 100% on two of them, lets see how C++26 compliance turns out to be, meanwhile C++17 parallel algorithms are only fully available in one of them, while the two other ones require TBB and libstdc++ to actually make use of them.
      - m-schuetz 1y ago
        I'm obviously not talking about modules-level features that may never get to see the light of day. A random(min, max) function isn't rocket science and already a major inprovement over the three-liner that is currently necessary. The major compiler devs won't take long to implement these cases, just as it did not take them long to implement simple yet useful functionality in previous versions of the standard. And the standard library is full with these cases of missing convenience functions over deliberately over-engineered functions.
        pjmlp 1y ago
        Modules have already seen the light of day in VC++ and clang. Anyone using a recent version of Office, is using code that was written with C++20 modules. It is relatively easy to see how far behind compiler developers are regarding even basic features. Note that two of the three major surviving compilers are open source projects, and in all three major compilers, the big names have ramped down their contributions, as they rather invest into their own languages, seeing the current versions as good enough for existing codebases.
    - account42 1y ago
      Well designed functions that deliberately target only 90% of use cases are fine. Badly designed library types that end up being effectively deprecated but you still need to deal with for decades because they end up in all kinds of interfaces are not.
  - Davidbrcz 1y ago
    I wouldn't mind if they actually _fix_ features afterward, even if it means breaking change.
    - account42 1y ago
      Users would mind though. Strong backwards compatibility is a very useful feature even if it does mean that you need to be careful about new additions.
  - lenkite 1y ago
    C++ really needs a fast-deprecate and kick out strategy for features that have proven to be poor - whether by bad design or bad implementation. And compilers should auto warn about such features.
  - pjmlp 1y ago
    Although C++ is one of my favourite languages, I feel the current WG21 process is broken, it is one of the few language evolution processes where proposals are allowed to be voted in without any kind of preview implementation for community feedback, or even to actually validate the idea. I have to acknowledge that none of the other ISO languages, including C, are this radical. That is how we are getting so much warts of lately. Unfortunelly there doesn't seem to exist any willingness to change this, until it will be too late to matter.
    - mgaunard 1y ago
      that's not true, implementations are more often required than not
  - gpderetta 1y ago
    std::future was caught in coroutine/network/concurrency/parallelism master plan that has been redesigned way too many times. Sender/Receivers is the the current direction, and while I don't dislike it, we are still far for a final design to cover all use cases (we still don't have a sender/receiver network library proposal I think). Whatever we end up with, std::future just wasn't a good base for an high performance async story. Still just adding a readiness callback to std::future would make it infinitely more useful even if suboptimal. At least it would be usable where performance is not a concern.
    - mgaunard 1y ago
      There is such a proposal
      - gpderetta 1y ago
        A recent one? Do you remember the doc number? edit: if you mean the concurrency TS, I think that's dead right?
        mgaunard 1y ago
        http://wg21.link/P2762 http://wg21.link/P2762

meindnoch 1y ago

>The article even mentions an arguably better approach (check on a timer), but for some reasons claims it is worse. How do you know what timeout to use for the timer? You may end up with tons of unnecessary polling if your timeout is too short, or high latency if your timeout is too long. >Standard C++ has one albeit somewhat overcomplicated, senders and receivers *in C++26

pjmlp 1y ago
Or CUDA, which is getting its own compute version.
mgaunard 1y ago
> how do you know what timeout to use? adjust based on your minimum expected latency, potentially with exponential backoff. Potentially account for scheduler overhead of the spurious wake-ups. Basically if you check every millisecond to every 10ms, you should be fine. > in C++26 it's a library, language support is not necessary. There are implementations you can use right now.

OskarS 1y ago

I think the idea is that you're using some external library (e.g. database drivers) which do not use asio but returns a std::future. You can't just "not use std::future" if that's what your library uses without fully rewriting your external library. The other option is as you mention polling using a timer, but I don't see how that's better, I'd rather move the work off of the event loop to a thread. And you then have to do the "latency vs. CPU time" tradeoff dance, trying to judge how often to poll vs. how much latency you're willing to accept.

mgaunard 1y ago
I'd argue using third-party libraries in a C++ project is a bad idea to begin with. Bad ones especially.

benreesman 1y ago

An imperfect but really useful standard for whether or not a C++ feature is going to work out is how long and troublesome the standardization process is. Modules? Never happening boys, the time has passed when anyone cares. Coroutines? Break gdb forever? Keep dreaming. Look at what they can do when it's clearly a good idea and has the backing of the absolute apex predator experts: reflection. If reflection can fucking sail through and your thing struggles, it's not going to make it. Andrew Kelley just proposed the first plausible IO monad for a systems language, and if I wanted to stay relevant in async C++ innovation I'd just go copy it. Maybe invert the life/unlift direction. The coroutines TS is heavily influenced by folly coroutines (or vice versa), a thing with which I have spent many a late night debugging segfaults. Not happening. Besides, if threads are too slow or big now? Then everything but liburing is.

cherryteastain 1y ago
Coroutines are well supported in boost::asio and are deployed in production in more places than you would think.
- benreesman 1y ago
  A second heuristic for things that aren't going to work out well is stuff that came from Boost. Oh sure, there was a time back in the TR11 days when it was practically part of the standard. But if it's on anyone's "cool, we'll link that, no problem" list in 2025? I don't know them.
  - spacechild1 1y ago
    Asio is actually independent from boost and it is by far the most popular C++ networking library.
pjmlp 1y ago
Not everyone is using C++ on Linux with GCC. There are people where modules and co-routines already happened, and there is better debugging experiences out there than gdb.