[regi]

"From SMTP filters/routers that handle millions of email deliveries a week to in-memory message journaling (for redundancy) that handle hundreds of transactions per second."

I stopped right there. To me, high performance is for instance, handling millions of emails per minute, thousands or tenth of thousand TPS. This is high performance, real life performance, not seen only in "physic labs and university research centers".

Some comments talk about Tcl using select. If this is true, it would mean a max of 1024 connections in parallel, kind of sad...

[incision]

>'I stopped right there.'

This is obnoxious, way too common and as another comment points out seemingly aloof to the fact that the article is 8 years old.

Please, just to stick to self-promotion [1][2][3][4].

1: https://news.ycombinator.com/item?id=6560909 2: https://news.ycombinator.com/item?id=6573974 3: https://news.ycombinator.com/item?id=8086250 4: https://news.ycombinator.com/item?id=8200975

[regi]

Oh, so this is your thing right? Checking people's background... https://news.ycombinator.com/item?id=8183055

;)

And as I'm saying in following comments, even in 2006, this was poor performance.

[rakoo]

This article was written in 2006. What was considered high performance at the time ? (genuine question)

[regi]

The C10k problem is 15-20 years old. Tcl uses select() which can handle a maximum of 1024 FDs. In other words, it would not be able to handle more than 1024 connections in parallel.

Moreover, Linux and FreeBSD have introduced syscalls comparable to select(): epoll (in 2002) and kqueue (in 2000). Those are way faster than select() and I think there's (virtually) no limit on FDs. Tcl must be using select() for its portability I guess.

So, handling a lot of concurrent connections is an old problem. In 2006, the C10k problem was way behind. Even at that time, I would have expected a program to be able to handle thousands of TPS.