[googie]

SQLiteStudio developer here. I think it's a project which could be considered big. Version 2.x.x was written entirely in Tcl and the main problem was memory sharing with threads. There's none. Threads can communicate only by messages. Worse than that - each thread has to load very same packages and same procedure definitions (into separate memory segment) for each thread that wants to use them. Threads in Tcl are like processes that can communicate through pipe. It's a major pitfall of this language in context of more complex projects. Besides that it is a very nice language to use and read. Gives quick results with little effort. I still use it almost every day, just not for complex projects.

I'm aware of tsv package (shared variable), but this is just sharing scalar variables or arrays. You cannot share objects, procedures, namespaces, resources, etc - and that is the major reason for sharing memory across threads.

[ArkyBeagle]

Tcl just totally wants to be event driven and single-threaded. I agree wholeheartedly with your assessment of threading in Tcl - the standard Tcl ideology is "don't use threads." It was a pretty deliberate decision as I recall.

[eggy]

Message passing without memory sharing. Isn't that what Erlang processes are? Is it because having to load the packages into the thread makes it too large? Just curious.

[googie]

I'm not familiar with Erlang. Nevertheless there are two main issues with this threading model:

1) Application memory consumption grows more than it should, because same extensions have to be loaded several times in the same application, but in separate threads;

2) Resources such as images (or any other kinds), or OO objects, cannot be transferred between threads efficiently, the only way is to serialize them to scalar representation, which then can be passed through either tsv (mentioned above) variables, or through a message to another thread - then deserialize them there. Apart from precious time which it costs, you also make a full copy of resource/object, growing memory consumption even more.

[ArkyBeagle]

Sockets aren't bad for serialization between threads in Tcl. Generally, a socket opened against localhost in Tcl is pretty smooth running. I have used multicast UDP sockets in anger with Tcl and it ran well.

For stuff that has to be fast, I generally reach for 'C', so I have not plumbed the depths of performance with sockets in Tcl.

Again, though, I drank the "everything is event driven" Kool-Aid years ago and it works for me.

[eggy]

I'm no expert with Erlang either, and thanks for the explanation. I have to look into Tcl/Tk for #1, but #2 makes sense to me now.