Re: ANN: threads enabled Itcl

Eckhard Lehmann napisal(a):
No, I didn't do it that way, exactly because deep copies are not easily
possible. (think of objects that contain objects as attributes etc...).

Actually, they are possible.

Please read: http://wiki.tcl.tk/3881

For showing the error with your Threaded Itcl: http://wiki.tcl.tk/16156


There is an ItclObject* structure representing each Itcl object - and
this one is shared between threads. When the '-threadshared' flag is
set, there is an access command for the object created in *each*
thread's interpreter - that's all. These access commands refer to the
same ItclObject* structure (so syncrhronization is really necessary
here, see http://wiki.tcl.tk/16140 near the bottom).

I meant object's variables.

The issue is that Tcl_Obj gets shared across threads. If thread A
creates a list and it gets modified by thread B (not in my example, but
it would also hurt, probably), weird things might happen.

This is because Tcl uses thread local variables to store things.

From what I remember with ns_cache from AOLserver, Tcl_Obj cannot be
shared between threads. So if this is true, your code will probably fail
when exiting Tcl or deleting the object, probably in a more complex
scenario.
Object deletion and thread exiting was indeed a tricky point and I
sometimes really racked my brain over debugging various scenarios
involving this. But finally I made it and hopefully it works forever
now ;-). Let me know if not...

It does not.

Tcl_Obj*'s are not shared as such. The ItclObject* structure is shared,
which has nothing to do with Tcl_Obj*. The only place where Tcl_Obj*
comes into play is, when the access commands are transferred via
tsv::get/tsv::set - and then they are just strings.
I started some kind of Tcl_Obj* representation for Itcl objects, but it
is rather useless at the moment. The code for this (in
generic/itcl_objtype.c) could be removed together with it's
dependencies and nothing would happen.

They are. Unless it can only work with using tsv::* instead of object
variables.

Also, how does it handle the following code:

namespace eval ::myns {}
A -threadshared ::myns::obj0

I would assume you may need to create the parent namespace in each other
thread.

As I've seen from Tcl_Create[Obj]Command(), the namespace is
automatically created if it does not exist.
The current patch has no regression tests for this case, but I just
extended the test suite with two tests - it seems to work correctly.

I believe it doesn't. That's why many extensions do Tcl_Eval(...,
"namespace eval ::namespace {}") before calling Tcl_Create*Command(). I
didn't check it, though.

.

Relevant Pages

  • Re: ANN: threads enabled Itcl
    ... same ItclObject* structure (so syncrhronization is really necessary ... scenario. ... when the access commands are transferred via ... I would assume you may need to create the parent namespace in each other ...
    (comp.lang.tcl)
  • Re: ANN: threads enabled Itcl
    ... For showing the error with your Threaded Itcl: http://wiki.tcl.tk/16156 ... > scenario. ... when the access commands are transferred via ... > I would assume you may need to create the parent namespace in each other ...
    (comp.lang.tcl)
  • Re: Class Variable Access and Assignment
    ... >>> b.a would refer to the same object. ... > will be resolved to two different namespace I don't see the relevance. ... > resolves to different namespaces. ...
    (comp.lang.python)
  • enum doesnt seem to work correctly
    ... I have an enum defined within a namespace. ... If I say "using namespace graphics;" then I can resolve the name of the ... // scenario 1: DOES NOT WORK ...
    (comp.lang.cpp)
  • Re: [Full-disclosure] Firefox: serious cookie stealing / same-domain bypass vulnerability
    ... On 2/15/07, Michal Zalewski wrote: ... including one scenario that apparently ... makes the script run with document.location in about: namespace. ...
    (Bugtraq)