The following came from the not uncommon Question/Answer pair
   Q: I Want Threads
   A: You Have An [Event] Loop

mailto:uwe-klein@foni.net (Uwe Klein) wrote in [the comp.lang.tcl newsgroup]:

Your answer says only that tcl has an event loop, but gives no 
explamation as to the differences / advantages.

1st Try:

POLLED

see if any in a list of jobs have to be done and process them. 
loop till dead.

THREAD

In a threaded program one will do each "primitive" loop of action
in its own thread.

 thread1 { block in read ; read file ; process read ; 
                                signal whats been done }
 thread2 { block on user input ; process user input ; 
                                signal for crt update  }
 thread3 { ...

Where threads interact they have to be synced somehow.

EVENT

In [event-oriented programming] one will set up an
event handler for anything that should / will happen. 

 event1 { fileevent readable datafile { do what must be done 
                        i.e. put data into dataarray } }
 event2 { writing to dataarray { compute depending values } }
 event2a { writing to dataarray { update crt } }
 event3 { button EXIT { clean up and exit }
 event4 { ...

Generated events are queued and then processed by the event loop.

If all dependencies are described correctly through  
"trace variable" , "fileevent", "widget -command" , .. 
any internal/external stimulus will cascade down 
its described dependecies.
Think of an event-looped program as something equivalent 
to a Makefile for your functional requirements.

Caveat: if your code contains "computing monoblocs" your
program becomes unresponsive.

[AMG]: Try moving these long calculations into child processes.  These programs take all their input from '''stdin''' or the command line arguments, write their results to '''stdout''', and abort by writing to '''stderr''' and [[[exit]]]ing nonzero.  If you want progress feedback, have them (optionally?) write that to '''stdout''' as well, and update your GUI when progress data is received.  Run the child process with [[[set] $chan [[[open] |[[[list] ''program'' ''arg1'' ''arg2'' ''...'']] a+]]]] and give it a [[[fileevent] $chan readable]] handler.  [[[puts] $chan]] all the data it needs.  Such programs can do one thing and quit, or stay running as long as your program runs.  (Example: a DNS lookup program, to dodge blocking gethostbyname().)

These programs can be written in any language (be open to the possibility that another language, say C, might be more appropriate, like in the DNS case), which is a nice feature, and also a good demonstration of Tcl's power as an integration (glue) language.  Also these programs can be run outside of your script; maybe they're useful all by themselves, as command line tools.



----
Note that the authors of "Why Events Are A Bad Idea"
[http://www.usenix.org/events/hotos03/tech/full_papers/vonbehren/vonbehren_html/index.html]
explicitly claim compatibility with [JO]s' recommendations;
their analysis of threading focuses on certain high-performance
servers.

----
[[[Arts and crafts of Tcl-Tk programming]|[Category Threads]]]