No argv, argc for worker thread
Bob Binder
* There is no way to send an option list to the interp started with
thread::create
* The argv and argc variables do not exist when an interp is created as a
worker thread.
For example, here's a command line start
> tlcsh -a 1 -b 2
% set argv
-a 1 -b 2
% set argc
4
% info vars
tcl_rcFileName tcl_version argv0 argv tcl_interactive auto_oldpath auto_path
errorCode errorInfo auto_index env tcl_patchLevel
argc tcl_libPat h tcl_platform tcl_library
%
Then, start some worker threads and ask for the same:
% package require Thread
2.6.2
% for {set thread 1} {$thread <= 3} {incr thread} {
set id [thread::create {
puts [info vars]
}] ;# thread::create
puts "*** Started thread $id"
} ;# for
*** Started thread tid00000AB8
*** Started thread tid00000BE4
tcl_version auto_path errorCode env errorInfo tcl_libPath tcl_patchLevel
tcl_library tcl_platform
tcl_version auto_path errorCode env errorInfo tcl_libPath tcl_patchLevel
tcl_library tcl_platform
*** Started thread tid0000086C
%
%
% tcl_version auto_path errorCode env errorInfo tcl_libPath tcl_patchLevel
tcl_library tcl_platform
-------------------
My questions are:
1) Is this really so?
2) If yes, any suggestions for a work-around which would allow scripts in
worker threads to receive argv?
tia
Bob
Don Porter
> It looks like
> * There is no way to send an option list to the interp started with
> thread::create
Don't know what you mean by that.
> * The argv and argc variables do not exist when an interp is created as a
> worker thread.
Yes. Same is true for an interp created by [interp create]:
% interp create slave
slave
% slave eval info globals arg*
%
So what?
> My questions are:
> 1) Is this really so?
Yes.
> 2) If yes, any suggestions for a work-around which would allow scripts in
> worker threads to receive argv?
If you want to set a variable in any interp, evaluate a script
in that interp that does so. Continuing the [interp create] example:
% slave eval "[list set argv $argv];[list set argc [llength $argv]]"
0
% slave eval info globals arg*
argv argc
Adapting this for [thread::*] left as an exercise.
--
| Don Porter Mathematical and Computational Sciences Division |
| donald...@nist.gov Information Technology Laboratory |
| http://math.nist.gov/~DPorter/ NIST |
|______________________________________________________________________|
Gerald W. Lester
I think you **really** need to take a closer look at Tcl threading model --
I believe you have a lot of false expectations based on (IMHO) broken
threading models in other languages.
Tcl threading model shares no (well, except for the global env array) data
or code between threads without you doing work -- as Don points out.
--
+--------------------------------+---------------------------------------+
| Gerald W. Lester |
|"The man who fights for his ideals is the man who is alive." - Cervantes|
+------------------------------------------------------------------------+
Bob Binder
I expected that a Tcl interpreter started in any manner would accept options
from its invoker and make them visible to scripts running in the resulting
interpreter.
Why?
* This is how the interpreter works with command line options
* Nearly all Tcl commands accept options of some kind, which are typically
visible in the target
* Using "args" in the proc and itcl method signature supports several Tcl
idioms
* Nothing in the Thread documentation indicates to the contrary
* Passing a list of options from the invoker which are visible to the target
is so common in Tcl, I'm really surprised that this isn't supported when
starting an interp in a thread or as a slave.
So, why not allow options to be passed in and made visible in the global
namespace?
The project at hand launches processes for Tcl app components, passing in
start up command line arguments. I'm refactoring a large component into
several threads. In all components, a "main" script processes command line
options. It then starts scripts or worker threads. The first thing done in
the worker thread is to run this same main script, which establishes the
common run time environment. So, to start a threaded component, I wanted
generate an options list and pass it along with the thread::create command,
just as I'm doing elsewhere. The common main script would process startup
options the same way in a worker thread as it does in the main thread. I
couldn't get that to work and implemented setting argv and argc using
variable passed through the tsv.
The purpose of my query was to confirm that what seemed to be a kluge was
necessary, and thanks for establishing that it its. Deciding whether this
asymmetry is feature or a gotcha is left as an exercise.
Bob
Neil Madden
> * This is how the interpreter works with command line options
Technically, this feature (setting argv/argc) is done by the tclsh and
wish applications, rather than by Tcl the language/library (see e.g.
tclsh(n) manpage).
> The purpose of my query was to confirm that what seemed to be a kluge was
> necessary, and thanks for establishing that it its. Deciding whether this
> asymmetry is feature or a gotcha is left as an exercise.
Well, it seems reasonably easy to implement this on top of the provided
functionality, as Don Porter demonstrated. However, perhaps you could
propose this as a Feature Request for the Thread extension at SourceForge?
-- Neil
Don Porter
> The purpose of my query was to confirm that what seemed to be a kluge was
> necessary, and thanks for establishing that it its. Deciding whether this
> asymmetry is feature or a gotcha is left as an exercise.
It's interesting how the particular uses folks have for Tcl come to be
seen as the "normal" way to use Tcl, and other approaches look weird,
if not invalid.
You're looking for argv and argc, because in the ways you use Tcl,
they're always there, and now you see them missing, and think there's
something wrong.
From a different perspective (embedding with the C interface, etc.),
the presence of argc, argv is what is weird; it's a special
convenience put in place by the tclsh and wish programs. Not strictly
a part of Tcl at all. From this perspective, it's weird to see folks
asking for argc, argv -- especially in an interp that's not tied
to any Tcl_Main or similar main routine in a master thread.