From: Laci <fo...@fr...> - 2003-07-17 09:18:02
|
I see! But i have read this: (link: http://groups.yahoo.com/group/tcl_announce/message/1361) Summary of Changes since version 2.2: ------------------------------------- o. New set of thread shared variable commands. It is a complete rewrite, allowing you to store Tcl objects in thread shared arrays. In the previous release, only the object string representation has been stored, affecting performance when building large and complex shared data structures. Much care has been taken internally to get a safe and protected shared object storage w/o explicit external locking. It is now very fast and convenient to use. All new commands reside under the "tsv::" namespace. For the backward compatility with the 2.2 version, all sv_* commands are still available. Please note that support for those might be dropped in future (major) releases of the extension. Laci > On Wednesday 16 July 2003 20:55, you wrote: > > Example: > > > > class Auto { > > variable _color "" > > > > public method setColor {color} {set _color $color} > > public method getColor {} {return $_color} > > > > public proc new {} {return [Auto ::#auto]} > > } > > > > set audi [Auto::new] > > $audi setColor red > > > > Can i share audi variable (object)? > > > > Now, we're gettting closer.... > And the answer is: no. > > Rationale.... > > Tcl uses the compartment threading model where all > resources created by Tcl in an Tcl interpreter are always > bound to that interpreter. Examples are: channles, commands, > namespaces, etc. Now, since Tcl interps are bound to a thread > that created them, you can not share mentioned Tcl resources. > > The only way one could achieve this would be to write the object > serializer which synthetizes a Tcl script representing the object > and then pass this script to the remote thread to re-create > the object. That is, some kind of object marshalling would be needed. > > I know you wont't be very happy with the answer. I'm not either. > But out of my experience (I use XOTcl instead of incrTcl) > I'm able to work-arround this limitation quite successfully and > have written quite a complicated MT-application using OO > constructs and threads. > > Zoran > > > > > |