[btmorex]

I don't believe that you have too many active connections for threading to work. Passive connections can be handled by a single or small number of threads. Modern Linux on modern hardware has no problem with many thousands of threads and the overhead is minimal in $$$ compared to the time you wasted debugging a scheduling problem.

As for concurrent systems being harmful, you just have to design your program for threading in mind. Minimize shared state and be very careful when you can't.

[rlpb]

> the overhead is minimal in $$$ compared to the time you wasted debugging a scheduling problem.

Better than time wasted debugging the races and deadlocks that only threads can cause. These are much harder to debug because they are so much harder to examine without changing behaviour.

Sure, there's a trade-off - so there's no point in pretending that there are no downsides to using threads.

[cperciva]

One connection can have many outstanding requests.

[btmorex]

I would redesign your protocol to be request/response based akin to http. Achieve performance by using multiple connections in the client. Simplicity > efficiency especially if you don't have the engineering resources of a company like Google.

And I'm out. The reply rate limiting is infuriating.

[hamburglar]

It's really easy to glibly criticize someone else's design decisions when 1) you don't have a full understanding of their problem, architecture, or rationale for that architecture, and when 2) the medium of the conversation doesn't lend itself well to providing you a satisfactory explanation.

It seems as though you've gotten the tiniest glimpse of some details about the system and went on to assume he made a boneheaded decision and you know better. Do you have some secret evidence that he's incompetent and doesn't have a good reason for his decision?