tcl threads 2.1 question?
Mel
awkward to have to use send. send command means "NO THREAD" to me!
thank,Mel
Jeff Hobbs
>
> is there anyway i could share global variables with threads. it is
> awkward to have to use send. send command means "NO THREAD" to me!
You have to use the latest thread package and Tcl 8.4+ which
has the shared variable commands.
--
Jeff Hobbs The Tcl Guy
Senior Developer http://www.ActiveState.com/
Tcl Support and Productivity Solutions
David Gravereaux
https://sourceforge.net/project/showfiles.php?group_id=10894&release_id=51364
It has yet to be doc'd, but have a look at the thread::sv_* stuff.
Microsoft Windows 2000 [Version 5.00.2195]
(C) Copyright 1985-2000 Microsoft Corp.
C:\WINNT\system32>tclsh84t
% package require Thread
2.2
% join [lsort [info commands thread::*]] \n
::thread::cond
::thread::create
::thread::errorproc
::thread::exists
::thread::id
::thread::join
::thread::mutex
::thread::names
::thread::send
::thread::sv_append
::thread::sv_array
::thread::sv_exists
::thread::sv_get
::thread::sv_incr
::thread::sv_lappend
::thread::sv_set
::thread::sv_unset
::thread::transfer
::thread::unwind
::thread::wait
%
--
David Gravereaux <davy...@pobox.com>
Tomasoft Engineering, Hayward, CA
[species: human; planet: earth,milkyway,alpha sector]
Please be aware of the 7.5 year ping times when placing a call from alpha centari
Chi Hung Chan
> is there anyway i could share global variables with threads. it is
> awkward to have to use send. send command means "NO THREAD" to me!
>
> thank,Mel
$ tclsh
% package require Thread
2.1
% info command thread::sv_*
::thread::sv_get ::thread::sv_lappend ::thread::sv_incr
::thread::sv_append ::thread::sv_exists ::thread::sv_set
::thread::sv_unset ::thread::sv_array
% set tcl_version
8.3
%
You can use the sv_ commands (shared variable) to exchange info
between different threads.
Cheers,
--Chi Hung
chi...@mbox2.singnet.com.sg
Frank Pilhofer
> ::thread::sv_append
> [...]
Just wondering about naming conventions. Why use prefixes (sv_), if we
got namespaces? In this case, why use a prefix at all?
Frank
--
Frank Pilhofer ........................................... f...@fpx.de
Astronomers point out that the universe is racing away from the
Earth at 15,000 miles per second. Can you blame it? - A. E. Neuman
David Gravereaux
>David Gravereaux <davy...@pobox.com> wrote:
>> ::thread::sv_append
>> [...]
>
> Just wondering about naming conventions. Why use prefixes (sv_), if we
>got namespaces? In this case, why use a prefix at all?
>
> Frank
Umm, whatever.
Zoran Vasiljevic
> Just wondering about naming conventions. Why use prefixes (sv_), if we
> got namespaces? In this case, why use a prefix at all?
>
Hi Frank.
I am the initiator (of problems!) of the thread::sv_* interface ;-)
Some background info up front.
If you know AOLserver, then you're probably acquainted
with "nsv" interface (nsv_get, nsv_set) etc. This was taken
as the initial model, since already proven to work.
So, some time ago, I asked the (c.l.t) group about the naming
convention we could use. There was no consensus so I
picked up what we currently have.
I agree that we might just pick some other (convention)
provided most of the people are satisfied with it.
We could do:
thread::sv::unset
thread::sv:array
thread::sv::get
thread::sv::lappend
thread::sv::append
thread::sv::incr
perhaps?
Or even move it to its own namesapace (sv::set, sv::get, ...)
Are there any other ideas ?
BTW: I plan to add much more functionality to shared variable
containers (internal object storage instead of strings, much more
inplace manipulating commands, new shared data structures)
so it is very likely that command set will grow.
Cheers
Zoran
Don Porter
>> Just wondering about naming conventions. Why use prefixes (sv_), if we
>> got namespaces? In this case, why use a prefix at all?
Zoran Vasiljevic <zo...@archiware.com> wrote:
> We could do:
> thread::sv::unset
> thread::sv:array
> thread::sv::get
> thread::sv::lappend
> thread::sv::append
> thread::sv::incr
> perhaps?
>
> Or even move it to its own namesapace (sv::set, sv::get, ...)
> Are there any other ideas ?
For this example, I would prefer a single command, [thread::sv],
for the manipulation of shared variables, with all of the operations
as subcommands.
Having structured it that way, I would give the commnd a base
name less cryptic than "sv". Probably, [thread::shared].
But, those who write the code get to define it...
--
| Don Porter Mathematical and Computational Sciences Division |
| donald...@nist.gov Information Technology Laboratory |
| http://math.nist.gov/~DPorter/ NIST |
|______________________________________________________________________|
Jean-Luc Fontaine
> Frank Pilhofer wrote:
>
>>> Just wondering about naming conventions. Why use prefixes (sv_), if we
>>>got namespaces? In this case, why use a prefix at all?
>>>
>
> Zoran Vasiljevic <zo...@archiware.com> wrote:
>
>>We could do:
>> thread::sv::unset
>> thread::sv:array
>> thread::sv::get
>> thread::sv::lappend
>> thread::sv::append
>> thread::sv::incr
>>perhaps?
>>
>>Or even move it to its own namesapace (sv::set, sv::get, ...)
>>Are there any other ideas ?
>>
>
> For this example, I would prefer a single command, [thread::sv],
> for the manipulation of shared variables, with all of the operations
> as subcommands.
>
> Having structured it that way, I would give the commnd a base
> name less cryptic than "sv". Probably, [thread::shared].
I vote for that.
> But, those who write the code get to define it...
They must have the last word ;-)
Jean-Luc
Don Porter
>> But, those who write the code get to define it...
Jean-Luc Fontaine <jfon...@winealley.com> wrote:
> They must have the last word ;-)
Not in Tcl, where we have [namepsace import] and [rename] !
Stuart Cassoff
> If you know AOLserver, then you're probably acquainted
I'm curious about the relationship between AOLServer's threads and the
current implementation. The AS people did a lot of work on threading, and
other work (bugfixes?) on Tcl. Of course the Tcl people work on Tcl which
benefits the AS people.
How much exchange goes on between these two groups?
Stu
Jeff Hobbs
>
> Zoran Vasiljevic wrote:
> > If you know AOLserver, then you're probably acquainted
>
> I'm curious about the relationship between AOLServer's threads and the
> current implementation. The AS people did a lot of work on threading, and
> other work (bugfixes?) on Tcl. Of course the Tcl people work on Tcl which
> benefits the AS people.
Threading was originally (?) introduced publically by Richard Hipp's
pttcl for 7.x (pthreads tcl). AOLServer, probably around the same
time, did lots of hacks to make a highly scalable, stable version of
Tcl (7.x era) to use in AOLServer (originally NaviServer).
When the Tcl group got around to making 8.1 thread-safe and thread-
aware, the AOL guys provided a lot of input and ideas about what
worked best for them. Other ideas came in from other places as
well, but the AOL guys (notably Jim Davidson) were influencial in
having the largest installation working with a threaded Tcl. As
AOLServer moved from their special 7.6 to 8.2, heads were together
to make sure things worked right.
Stuart Cassoff
> Threading was originally (?) introduced publically by Richard Hipp's
Thanks, my curiosity is sated.
Stu
Tom Poindexter
No slight to Richard, but I think there was 'mttcl' by Steve Jankowski
earlier:
http://www.ensta.fr/internet/solaris/mttcl.html
--
Tom Poindexter
tpoi...@nyx.net
http://www.nyx.net/~tpoindex/
Cameron Laird
Tom Poindexter <tpoi...@nyx10.nyx.net> wrote:
>In article <3B97C2A8...@sympatico.ca>,
>Stuart Cassoff <st...@sympatico.ca> wrote:
>>Jeff Hobbs wrote:
>>> Threading was originally (?) introduced publically by Richard Hipp's
>>...
>>
>>Thanks, my curiosity is sated.
>
>
>No slight to Richard, but I think there was 'mttcl' by Steve Jankowski
>earlier:
>
>http://www.ensta.fr/internet/solaris/mttcl.html
.
.
And is Jim Davidson's a separate line of development?
--
Cameron Laird <cla...@NeoSoft.com>
Business: http://www.Phaseit.net
Personal: http://starbase.neosoft.com/~claird/home.html
Jeffrey Hobbs
> Tom Poindexter <tpoi...@nyx10.nyx.net> wrote:
> >Stuart Cassoff <st...@sympatico.ca> wrote:
> >>Jeff Hobbs wrote:
> >>> Threading was originally (?) introduced publically by Richard Hipp's
> >>...
> >>
> >>Thanks, my curiosity is sated.
> >
> >No slight to Richard, but I think there was 'mttcl' by Steve Jankowski
> >earlier:
> >
> >http://www.ensta.fr/internet/solaris/mttcl.html
That's what the (?) was for...
...
> And is Jim Davidson's a separate line of development?
He was the one that did the NaviServer->AOLServer work.
Zoran Vasiljevic
> Don Porter wrote:
> >> But, those who write the code get to define it...
>
> Jean-Luc Fontaine <jfon...@winealley.com> wrote:
> > They must have the last word ;-)
>
> Not in Tcl, where we have [namepsace import] and [rename] !
>
... which should be avoided (IMHO) since it creates numerous
(maintenance) side-effects.
Freedom comes with a price, as everything in life...
Zoran Vasiljevic
> For this example, I would prefer a single command, [thread::sv],
> for the manipulation of shared variables, with all of the operations
> as subcommands.
That would mean (for the command now in 2.1(2) version):
thread::sv names
thread::sv get arrayName element
thread::sv set arrayName element value
thread::sv incr array element ?value?
thread::sv exists arrayName ?element?
thread::sv unset arrayName ?element?
thread::sv append arrayName element value ?value ...?
thread::sv lappend arrayName element value ?value ...?
I plan to extend this with some list commands that do
mainly list manipulations on shared data, inplace:
thread::sv llength
thread::sv lrange
thread::sv lreplace
thread::sv lindex
thread::sv lsearch
thread::sv lpop (pops arbitrary element from the list)
Those have the same syntax as their Tcl counterparts
but with list operand passed per reference instead of value
(due to necessary internal locking) like for example:
% thread::sv lappend myArray elemen1 quick brown fox
% thread::sv lreplace myArray elemen1 1 1 yellow
% thread::sv get myArray elemen1
=> quick yellow fow
They are mainly there so one can implement rather complex
shared structures without copy them in string form back and forth
between threads. Also, I already have implementation of shared
keyed lists (a'la TclX) and implementation of shared dictionaries
(borrowed from Frederic Bonnet), but their inclusion in thread
extension is still to be discussed.
If there are no voices against, I can make this into the 2.3
I do however plan to leave the current sv_* command there
for backward compatibility until we come to 3.0.
Zoran
Don Porter
>> Not in Tcl, where we have [namepsace import] and [rename] !
Zoran Vasiljevic <zo...@archiware.com> wrote:
> ... which should be avoided (IMHO) since it creates numerous
> (maintenance) side-effects.
I disagree. When used properly, there are *no* maintenance
issues with [namespace import] and [rename].
Sure, if one stays in the Tcl 7 mindset, and [rename]s commands
that other modules are expecting to find by their original name,
you can get in a heap of trouble. You are correct to say "Don't
do that!"
But with namespaces, every module author gets to be master of
his domain -- the namespace of his module. In that namespace
he controls all the names of all the commands.
Example:
# Someone provides the thread package with a thread::shared command:
namespace eval thread {
namespace export shared
proc shared {option args} {...}
}
# Author of the foo package has different opinions about names:
namespace eval foo {
namespace import ::thread::shared
# Shared what? What a stupid ambiguous name!
rename shared sharedVariable
proc myLongCommandName {} {...; sharedVariable set counter 1; ...}
}
# Author of the bar package has yet a third view:
namespace eval bar {
namespace import ::thread::shared
# Stpd thrd pkg gonna give me RSI.
rename shared sv
proc x {} {...; sv set x 1; ...}
}
Each developer gets the environment he prefers without intruding on
the preferences of other developers.
Zoran Vasiljevic
> But with namespaces, every module author gets to be master of
> his domain -- the namespace of his module. In that namespace
> he controls all the names of all the commands.
>
> Example:
>
> # Someone provides the thread package with a thread::shared command:
> namespace eval thread {
> namespace export shared
> proc shared {option args} {...}
> }
>
> # Author of the foo package has different opinions about names:
> namespace eval foo {
> namespace import ::thread::shared
> # Shared what? What a stupid ambiguous name!
> rename shared sharedVariable
> proc myLongCommandName {} {...; sharedVariable set counter 1; ...}
> }
>
> # Author of the bar package has yet a third view:
> namespace eval bar {
> namespace import ::thread::shared
> # Stpd thrd pkg gonna give me RSI.
> rename shared sv
> proc x {} {...; sv set x 1; ...}
> }
Well, I must admit...
I just *love* this example!
After 7 years of Tcl'ing, such obvious and elegant,
yet simple solutions to otherwise rather ugly problems
can still blow may pants off!
Thanks for pointig this out, Don.
Zoran