Idioms: Building High Performance Networking Servers Using Tcl (2006) | Hacker News Reader

Idioms: Building High Performance Networking Servers Using Tcl (2006)

maplefish.com

38 pointsghosthamlet18 comments

Tcl - doing event loops before event loops were cool.

I think the article is from 2004 instead of 2006. None the less, i'm wondering if this statement still stands:

    Tcl is slower than C, but the network is slower than Tcl.

It's apt to compare Tcl to Node.JS because of the similar I/O-model.

Tcl is slower than Node.JS (a broad statement, but e.g., it's not JITed), and the last time I checked Tcl's event loop was select-based and not epoll/kqueue-based. Looking at the code for 8.6.2, it appears to be like that still.

I like Tcl, but I wouldn't use it for high-concurrency tasks (I would use Go for that). It's nice when you need a DSL to extend your application, or if you want to glue C libraries together, but there are better tools for network code.

The similar IO model? It is just the Unix IO model though, with the caveat to never use blocking IO. Tcl doesn't force non blocking IO like Node, you have to do it yourself.

Event based IO was around by 1999 or earlier, according to the C10k page that we all avidly read backin the day http://www.kegel.com/c10k.html

Both Tcl and Node.JS are built around the concept of an event loop. The preffered way to do IO in both languages is to express your network application as a FSM with callbacks on state transitions. Of course event driven IO is not in any way "owned" by either languages, what I mean is that they both encourage an event-driven IO model.

Am I making myself clear?

F5 load balancers still use Tcl, albeit a modified and optimised version.

If anyone is reading this article and thinking "Gee, I wish I could get a job writing Tcl", hit me up.

iRules are a horror that should've been killed at birth.

For me it's more like gee, I had a job writing Tcl and it was so much "fun". I've just tried the example from "Read messages chunk by available chunk" and got:

    invalid command name "handle_data sock4"
        while executing
    "[list handle_data $chan] "
        (procedure "handle_client" line 8)
        invoked from within
    "handle_client sock4 127.0.0.1 40642"

I replaced [list handle_data $chan] with a plain handle_data $chan, but then another bug come up:

    invalid command name "buf"
        while executing
    "buf sock4,data_ready write"
        (write trace on "buf(sock4,data_ready)")
        invoked from within
    "set buf($chan,data_ready) 0"
        (procedure "handle_data" line 4)

The fun never stops :-) In a way Tcl makes shell scripting (Bash) look wonderful because at least there you can't expect much from it, whereas Tcl presents itself more like a "real", full-blown programming language.

Your error looks like there might be an extra space after the line continuation (backslash) in the example.

The trace command is split in to 2 lines for readability but the web page's formatting introduced a hidden space if you try to copy/paste the example in to a tcl script.

Yes, you're right.

The Cisco IOS operating system includes TCL scripting as well.

I just picked up PureData and have been enjoying learning about it and sound generation - also written in tcl/tk!

I know this articles was published 7-8 years ago at http://idioms.in

"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...

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

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.

>'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

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.

Reply on news.ycombinator.com