Hacker News Reader

Comment by ofrzeta | Hacker News Reader

The article says "Tcl’s innate asynchronicity". Does anybody who knows Tcl care to tell more about this?

Tcl has built-in event loop functionality. You can put watches on file channels, network sockets or synthetic scripted channels, start the event loop, and have a completely event-driven program.

Writing a simple web server, for example, is trivial.

Tk accesses the C-based event API to turn things like button clicks into events. Python (and Ruby?) ships with Tcl in order to make use of Tk.

There's a thread extension that makes it easy to spawn separate threads which can inject events into the event loop, making hybrid event/thread programming simple.

This is right. It's "innately async" in the same way as Node: there is a built in event loop, and just about anything that could block (file I/O, GUI input, etc.) can be accessed through async functions instead.

One nice thing about Tcl vs. Node: Tcl doesn't crash if there's an error in one of the asynchronous call stacks. The Tcl interpreter catches the error and passes it to a (customizable) background error processor, and keeps going.

That's right. My first reaction after learning Node was that its Tcl/TK done poorly but with a faster runtime. Tcl/Tk had first class event loops from the beginning (of time), later it acquired coroutines as well.

The best part for me, however, was that in Tcl you can have multiple interpreters in the same process, each in its own native thread if you want. No GIL, no need to pickle/unpickle to talk the other interpreter. Had Python adopted this model, using multiple cores would have been so much nicer.

That said, the mantle has passed on to Lua, but I still harbor a soft corner for Tcl.

How different are tcl and node from select, poll, and epoll?

I know tcl and node are runtimes - but what do you get extra in their event loops compared to standard event loops that Linux offers?

It is difficult to compare languages with operating systems on which those languages can be executed/evaluated.

On systems that implement them, Tcl can use select, epoll, kqueue for its event notification implementation, as well as pthread_cond_broadcast for threads (if built with thread support).

take a look at:

generic/tclNotify.c - https://core.tcl.tk/tcl/artifact/8804164706c8f2cb

unix/tclEpollNotfy.c - https://core.tcl.tk/tcl/artifact/892b68fa5a7c4c87

With select/poll, you have to write your own dispatcher, which means you have to care about details like whether you need round-robin to prevent early things in your fdset stopping later things being processed, etc. Also, many of the things you'd like to wait on aren't file descriptors, so you have to do extra work to make them fit. My bugbear for this is pthread condition variables, but it's also true of most GUI toolkits, which expect you to use some variation of while(Toolkit_GetEvent(&event)). You can work around these, of course, it's just mildly annoying extra work.

I wouldn't call Tcl "innately async" like, for example, Erlang.

Tcl is a command-based, imperative language. Tcl has threads.

They work mostly like you'd expect: shared variables, mutexes, condition variables.

Threads can send script code to another thread using thread::send -async and thread::broadcast:

https://www.tcl.tk/man/tcl/ThreadCmd/thread.htm#M17

Tcl does let you write DSL-like libraries, and because you can easily hotswap code (being homoiconic like Lisp), it also works well for distributing your execution environment across several network nodes.

But the language itself isn't "innately async". The thread model isn't based on message passing, CSP, Pi calculus, or any other strong idea. I always thought of it as "string-focused Lisp".

Reply on news.ycombinator.com