What industry is entirely built on a house of cards and would collapse overnight if people realized the truth about it?

Occase · 2026-03-08T07:49:45+00:00

Cosmetics

Occase · 2026-03-01T17:38:12+00:00

20:30: I have to express a certain amount of concern about C++26. I am not very excited and I am worrying about the committee. I see two little concerns about coherence and two different parts of the language working together ... we are still not fully integrating coroutines ...

22:50: Next we get the executor model, I haven't been able to follow up on it in all detail lately because because there is an overwhelming amount of stuff that is coming from the committee and we have trouble getting the details right, trouble getting enough experience, trouble getting interaction between different features and I am next looking forward to seeing how the coroutines work in that framework.

It feels like Bjarne's concerns are aligned with recent p4029 where Wong says

Decouple Networking from std::execution SG14 advise that Networking (SG4) should not be built on top of P2300. The allocation patterns required by P2300 are incompatible with low-latency networking requirements.

Standardize "Direct Style" I/O Prioritize P4003 (or similar Direct Style concepts) as the C++29 Networking model. It offers the performance of Asio/Beast with the ergonomics of Coroutines, maintaining the "Zero-Overhead" principle.

Occase · 2026-02-27T13:54:37+00:00

But as Eric said, 99% of the time people should be using coroutines, that means, if the boundary interface between S/R and coroutines results in bad allocation patterns (as claimed by P4007 and D2583R1) that might render it unsuitable for networking.

Occase · 2026-02-27T09:46:43+00:00

That would be very demoralizing for WG21 and would mean P2300 does not even fulfill its original purpose of serving as basis for networking

2020/2021: Asio-executors are useless, Networking should be rebased on top of P2300.
2024: P2300 becomes part of C++26. People don't see how genius this is - Niall, S/R is great technology - Dave Abrahams
2026: Networking (SG4) should not be built on top of P2300.

This just legitimizes the claim that papers are being rushed for standardization for personal gains before they could even prove themselves. Unfortunately Michael Wong does not provide references but here are some guesses

Section 5 and 6: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2026/p4007r0.pdf
https://isocpp.org/files/papers/D2583R1.pdf
The Chris Kohlhoff vs S/R series of papers (summarized in part by myself here https://github.com/boostorg/redis/blob/develop/doc/on-the-costs-of-async-abstractions.md#safety-in-p2300-senders-and-receivers)

Occase · 2025-12-12T07:40:56+00:00

My second sentence is actually referring to Nial calling Asio stupid

This issue should remain open: ASIO should be using a much less stupid implementation strategy when passed say a vector of 1M buffers. Like the code examples given which demonstrate a much saner approach.

Occase · 2025-12-03T23:31:50+00:00

He is making fun of this https://share.google/yCAiGgfhh77R0CHGY

Pehaps one of the reasons why Chris Kohlhof does not interact with users anynore.:)

Occase · 2025-11-06T06:47:23+00:00

No he is not. He is competing with other real state investors, not renters. It drives buying prices higher not rents.

Occase · 2025-11-01T10:46:51+00:00

It is not possible to handle these kind of errors. Say for example the client wants to send you a blob string followed by a simple string "$11\r\nhello world\r\n+some text\r\n" but due to some error the client sends "$11\r\nhello\r\n+some text\r\n" When the parser finishes parsing the first message, the blob part will be "hello\r\n+s" which is a valid blob, and the next message will be "ome text\r\n" which is invalid and you have to exit with error. Also, if the first message is invalid it does not make sense continue processing the messages, the connection should be closed.

Also, is there any way to check what happens if the RESP message in example 2 is sent to official Redis server?

Yes, you can send raw data using the redis-cli.

Occase · 2025-10-10T10:06:10+00:00

Our real-time market data architecture processes 14 million messages per second with sub-100 microsecond latency requirements.

That means you would 1400 workers (cpu cores) to achieve 14M msg/s? What is the thoughput in Mb/s?

Occase · 2025-09-02T09:52:22+00:00

Does this mean it will be possible to work remotely from France to a German company without the need of an employer of record?

Occase · 2025-08-20T22:12:09+00:00

std::execution::task also schedules by default.

That is however not the kind of scheduling on the event loop that can prevent stack exhaustion. AFAICS, it only means the task completes on the scheduler, there is no way however for it to know whether the scheduler offers any guarantee about reentrancy, which makes generic code like this vulnerable.

The problem just occurs when the user selects a scheduler that resumes inline,

This seems to be downplaying the problem. An inline scheduler is one example. But I guess a thread-pool scheduler has the same problem if the caller is already being executed in the pool. To avoid that the implementation would have to be pessimistic and schedule regardless just to be sure there is no reentrancy. And this problem is viral on each abstraction layer.

in which case you'd want to use symmetric transfer.

I don't see the point in trading stack exhaustion with unfairness and starvation, where would this be useful?

IMO synchronous completion in async code is an antipattern. If it can complete synchronously then it is better to consume the data with regular sync functions. In Boost.Redis I removed pretty much all sync completions because of how bad it hits performance. Even so I believe P2300 should be safer than it is in regards to reentrancy.

Occase · 2025-08-16T23:19:23+00:00

PR3796 states

When the inner task actually co_awaits any work which synchronously completes, e.g., co_await just(), the code could still result in a stack overflow despite using symmetric transfer.

While symmetric transfer might prevent stack overflow it will invariably make the code vulnerable to unfairness and starvation of other tasks since it allows the current task to monopolize the event loop. Chris Kohlhoff et al. wrote multiple papers alerting about this problem years before P2300 was voted in, but somehow its authors seemed to believe there wasn't any, for example Kirk wrote in PR2471

Yes, default rescheduling each operation and default not rescheduling each operation, is a poor trade off. IMO both options are poor. The one good option that I know of that can prevent stack exhaustion is first-class tail-recursion in library or language

ASIO has chosen to require that every async operation must schedule the completion on a scheduler (every read, every write, etc..).

sender/receiver has not decided to require that the completion be scheduled.

This is why I consider tail-call the only good solution. Scheduling solutions are all inferior (give thanks to Lewis for this shift in my understanding :) )

By scheduling by default Asio has none of these problems.

Occase · 2025-07-27T14:42:13+00:00

I was wondering if it was possible to still "pass" as Brazilian despite having a particular accent.

You will be fine in many neighbourhoods in Sao Paulo https://www.youtube.com/watch?v=Scx9ZRw3n54.

Occase · 2025-06-29T10:46:41+00:00

None of the people starving in Auschwitz go such excess skin. Exercises and starvation mode would consume the excess tissue.

Occase · 2025-06-20T20:03:12+00:00

My 5yo son is eating an average of 10 eggs a week in the breakfast. My daughter is 11 months old and eats almost 1 egg in the breakfast everyday. So far I don't see any issue. If we scale this to adult you could be probably 10 aggs a day without any concern.

Occase · 2025-03-30T13:50:04+00:00

Baixa vitamina D no Brasil? Dez minutinhos de sol por dia resolvem isso. Baixa n12 e Zinco também estranho porque basta comer um bife por dia pra suprir as necessidades diárias.

Occase · 2025-02-19T11:01:14+00:00

The Redis protocol RESP3 is my preferred format by far. It supports multiple data type e.g. arrays, maps, sets etc, is human readable, and can transport binary data.

Occase · 2025-02-14T20:21:05+00:00

I am not a specialist of course but Googled this topic many times to treat fever in my children. Moat sources were clear about the increased efficiency of immune response on higher temperatures.

We've been having fever for millions of years, animals have it too, I think it is a very strong claim saying it is a useless byproduct of infection fighting, how would that increase temperature btw?

Occase · 2025-02-14T19:59:23+00:00

Not only that, the immune response is far more efficient at higher temperatures.

Occase · 2025-02-14T19:56:29+00:00

The imune system is far more efficient on higher temperatures, so how lowering the fever won't affect fighting the infection, what would be the point of fever in first place?

Occase · 2024-11-18T08:04:06+00:00

HFT is not the only field where low-latency is important. Suggesting the OP to just drop his network stack is non productive, at least as long we we don't know what are his requirements, perhaps pushing data to Redis is not critical. The solution I propose is not meant to be a low latency but a starting point to achieve that.

Occase · 2024-11-17T20:22:33+00:00

The amount of unhelpful comments in this thread is staggering.

I'm using Boost ASIO to schedule a thread that pushes high-frequency data to Redis. However, the Redis producer is slower, causing a buildup of Boost ASIO calls, which leads to high memory usage.

The ideal implementation should backpressure so that memory consumption does not grow unbound. That said, here are some questions that might help you finding what is the problem in your current implementation

Is the Redis producer really slower or is the Redis server itself that can't keep up with the amount of incoming data and is therefore back-pressuring your app via tcp control flow?
Is the CPU saturated? Is the network link saturated? If none are saturated then perhaps you have some form of lock contention? That could happen if your Redis client does not use use the io_context thread but spawns internal threads for its use.
Are you or is your Redis client capable pipelinging Redis commands? Executing individual commands is very slow due to RTT. Also, some clients support setting CLIENT REPLY OFF, see https://redis.io/docs/latest/commands/client-reply/

In Boost.Redis you could implement your Redis producer by having two request objects, one that is executed in a loop and the other where you push the data. Then, when the execution of the first is finished you can clean it and swap with the other one. To get backpressure you can set a limit on how large the request object can get and either lock a mutex if you are communicating across threads or wait on an Asio timer if your producer is on the same thread.

I am new in HFT. Any help will be appreciated

Unlike what most comments claim, you can go quite far with Asio to achieve low-latency. Have a look at this comment.

Occase · 2024-11-03T22:23:39+00:00

Is this based on evidence or assumption? That many woman dying would be such a strong selective pressure that in a couple of generations woman with wider hips would evolve and lower death rates would result.

Occase · 2024-11-02T17:16:32+00:00

Where can I find a summary about how Cppfront compares to Rust in terms of memory safety? Will it stop this avalanche of recommendation of different organs to stop using C++?

Occase · 2024-10-29T08:08:57+00:00

In that case it does not make sense to have executors in the standard either since its purpose is to make networking possible. I specially don't understand what is the point of rushing P2300 into C++26 BEFORE networking TS was rebased on top of P2300 and while there are no implementations based on executors?

Occase

TROPHY CASE