tcl and threads: installing and other info
susara
threads. I'm not a TCL expert, so I've been looking on the web for some
info on how to go about it. But I'm not able to find authoritative
documentation on what the state of TCL's various thread extentions are,
and how to go about implementing it. If someone could please point me
to some docs i'd be grateful.
I do understand thread programming itself; I've done that in C. What I
struggle with is the TCL support for threads. It seems there's an
authoritative C implementation that hooks into the TCL interpreter, and
it seems various people have built TCL APIs on top of that. I've found
references to a Thread package, and there's an mkThreads extention, and
aparently a few others as well.
So I've got questions like:
- Which of these extentions are most up-to-date and stable?
- Aparently one has to build your TCL installation with
--threads-enabled. Now I've got both debian and slackward production
boxes; how do I know whether these boxes' tcl environments have been
built with thread support?
- on a test debian box i've done apt-get install tclthread. That makes
available package Thread, version 2.5. How up-to-date is that? Why
can't I go "man n thread::create" after this installation?
Etc.
Any help/pointers appreciated.
Neil Madden
> I'm extending tcl code developed by someone else, and will have to use
> threads. I'm not a TCL expert, so I've been looking on the web for some
> info on how to go about it. But I'm not able to find authoritative
> documentation on what the state of TCL's various thread extentions are,
> and how to go about implementing it. If someone could please point me
> to some docs i'd be grateful.
"Practical Programming in Tcl/Tk", by Welch, Hobbs etc has a chapter on
threads, which is available on-line from http://www.beedub.com/book/ .
It should be reasonably up-to-date.
>
> I do understand thread programming itself; I've done that in C. What I
> struggle with is the TCL support for threads. It seems there's an
> authoritative C implementation that hooks into the TCL interpreter, and
> it seems various people have built TCL APIs on top of that. I've found
> references to a Thread package, and there's an mkThreads extention, and
> aparently a few others as well.
The Thread extension is the one you want, most probably. This is the
"official" threads extension, that builds on top of the core's built-in
thread support. I've not used mkThreads.
>
> So I've got questions like:
> - Which of these extentions are most up-to-date and stable?
>
> - Aparently one has to build your TCL installation with
> --threads-enabled. Now I've got both debian and slackward production
> boxes; how do I know whether these boxes' tcl environments have been
> built with thread support?
Well, if [package require Thread] succeeds, then you have threads. Also,
in a threaded build the tcl_platform global array will contain a
"threaded" element, set to 1, i.e.:
if {[info exists ::tcl_platform(threaded)]} {
# In a threaded build
}
>
> - on a test debian box i've done apt-get install tclthread. That makes
> available package Thread, version 2.5. How up-to-date is that? Why
> can't I go "man n thread::create" after this installation?
All of the thread commands are under a single "thread" manpage, so just
"man n thread". There are also "tsv", "ttrace" and "tpool" manpages.
-- Neil
Eckhard Lehmann
susara wrote:
> documentation on what the state of TCL's various thread extentions are,
> and how to go about implementing it. If someone could please point me
> to some docs i'd be grateful.
http://www.tcl.tk/doc/howto/thread_model.html
> I do understand thread programming itself; I've done that in C. What I
> struggle with is the TCL support for threads. It seems there's an
> authoritative C implementation that hooks into the TCL interpreter, and
> it seems various people have built TCL APIs on top of that. I've found
> references to a Thread package, and there's an mkThreads extention, and
> aparently a few others as well.
Afaik, the Thread extension is the standard one. I've never heard about
other thread extensions...
>
> So I've got questions like:
> - Which of these extentions are most up-to-date and stable?
Thread 2.6.3:
http://sourceforge.net/project/showfiles.php?group_id=10894&package_id=10438
>
> - Aparently one has to build your TCL installation with
> --threads-enabled. Now I've got both debian and slackward production
> boxes; how do I know whether these boxes' tcl environments have been
> built with thread support?
$ tclsh
% set tcl_platform(threaded)
1
If Tcl was not built with threads, an error is generated:
"can't read tcl_platform(threaded)..."
>
> - on a test debian box i've done apt-get install tclthread. That makes
> available package Thread, version 2.5. How up-to-date is that? Why
> can't I go "man n thread::create" after this installation?
2.5 is old. I'd suggest to compile it yourself, maybe even compile Tcl
yourself (an installation of self compiled Tcl in /usr/local does not
interfere with the default installation).
Eckhard
Gerald W. Lester
> I'm extending tcl code developed by someone else, and will have to use
> threads. I'm not a TCL expert, so I've been looking on the web for some
Others have correctly pointed you to the threads package, but...
Before going there why do you think you will have to use threads?
The reason I ask is that 99% of the time you do not need to use threads in
Tcl to do what people need threads for in other languages. Most of the time
doing event driven programming instead of thread programming is the right
answer in Tcl.
--
+--------------------------------+---------------------------------------+
| Gerald W. Lester |
|"The man who fights for his ideals is the man who is alive." - Cervantes|
+------------------------------------------------------------------------+
Cameron Laird
susara <jud...@inet.co.za> wrote:
>I'm extending tcl code developed by someone else, and will have to use
>threads. I'm not a TCL expert, so I've been looking on the web for some
>info on how to go about it. But I'm not able to find authoritative
.
.
Along with what Neil and Eckhard have wisely advised, I feel
it's important to note that people "not a TCL expert" often
are in error when they believe they "have to use threads".
Tcl is like C in some ways, but different in others; in Tcl,
for example, a network server capable of handling a thousand
concurrent connections takes under ten lines to write.
Just for practice, then, say a few words about your
concurrency requirements. There's a fair probability that
we can suggest a Tcl-based approach that does everything you
need withOUT you having to mess with configuration options,
download new sources, or so on.
susara
Cameron Laird wrote:
> Just for practice, then, say a few words about your
> concurrency requirements. There's a fair probability that
> we can suggest a Tcl-based approach that does everything you
> need withOUT you having to mess with configuration options,
> download new sources, or so on.
Firstly thanks VERY much for the doc pointers, I'll go read up. Then,
my reasons for going off on a thread...
I've got a process that connects to a postgres db on the one hand, and
on the other accepts socket connections from subscription processes. It
waits on database notification events. On notify it has to do some
intensive processing and forward the results to the subscribed
processes. The processing will be pretty time consuming, and I'm pretty
sure those db notifications are going to come in faster than what I'm
going to be able to process.
So I'd like to parallelise the notification processing. The master
process will listen for the db notifications; fire off slave threads to
handle them, get the results back from each thread as it completes
processing and send it to the subscribed processes.
I'll have to protect some common data against concurrent access. I
could be lazy and use the database's locking mechanisms to coordinate
the slaves, but for performance I'd prefer to keep as much of this in
memory and somehow share it between them, using mutexes where
necessary. This in particular holds for the results that have to be
communicated back to the master.
If there is an elegant way of handling this without using threads I'd
be very happy. I really don't feel like messing around with installing
manually built libraries on a debian box, especially not a live system
that runs 24/7...
Michael Schlenker
> Cameron Laird wrote:
>
>> Just for practice, then, say a few words about your
>> concurrency requirements. There's a fair probability that
>> we can suggest a Tcl-based approach that does everything you
>> need withOUT you having to mess with configuration options,
>> download new sources, or so on.
>
> Firstly thanks VERY much for the doc pointers, I'll go read up. Then,
> my reasons for going off on a thread...
>
> I've got a process that connects to a postgres db on the one hand, and
> on the other accepts socket connections from subscription processes. It
> waits on database notification events. On notify it has to do some
> intensive processing and forward the results to the subscribed
> processes. The processing will be pretty time consuming, and I'm pretty
> sure those db notifications are going to come in faster than what I'm
> going to be able to process.
>
> So I'd like to parallelise the notification processing. The master
> process will listen for the db notifications; fire off slave threads to
> handle them, get the results back from each thread as it completes
> processing and send it to the subscribed processes.
Sounds like the correct architecture, a event based master process using
a recent Tcl postgreSQL interface and event based socket stuff to manage
the IO things.
But if your on linux you could use processes instead of threads for the
slaves, started with open | listening on a pipe, much easier and much
more stable in case one of the slaves crashes or does nasty things. If
in a thread it would kill you process, in another process you can just
close the pipe, kill the child and restart a new one.
As your using PostgreSQL you could even create much of the master
process as a stored procedure inside the database, called by triggers.
> I'll have to protect some common data against concurrent access. I
> could be lazy and use the database's locking mechanisms to coordinate
> the slaves, but for performance I'd prefer to keep as much of this in
> memory and somehow share it between them, using mutexes where
> necessary.
If you don't have enough memory for the database to do its
locking/concurrency control in memory your into swapping anyway.
Tcls thread model is message passing based, so you don't have shared
memory and mutex stuff usually, unless you explicitly request something
like it, see the thread package documentation for details.
>This in particular holds for the results that have to be
> communicated back to the master.
>
> If there is an elegant way of handling this without using threads I'd
> be very happy. I really don't feel like messing around with installing
> manually built libraries on a debian box, especially not a live system
> that runs 24/7...
As i said above. Use a master process that spawns new slaves as
processes when needed. Works perfectly well. I had such a system for
managing a distributed web crawler, where each agent-controller process
managed from 0-50 Perl processes on pipes, doing job control, recovering
from crashes of the perl scripts etc.
Btw. Tclsh on debian is threaded by default, see the entry in the
tcl_platform array by doing:
tclsh
% parray tcl_platform
Michael
susara
Michael Schlenker wrote:
> But if your on linux you could use processes instead of threads for the
> slaves, started with open | listening on a pipe, much easier and much
> more stable in case one of the slaves crashes or does nasty things. If
> in a thread it would kill you process, in another process you can just
> close the pipe, kill the child and restart a new one.
Ok I read up a bit about this and I think I'm going to give it a try
before I start fiddling with threads. Thanks for the good advice, you
might hear from me again ;-)