On Wednesday 09 May 2001 16:27, you wrote:
> Zoran, I just took a look at your tcl_sv code. I do not believe that it
> is thread-safe, but perhaps you can convince me. Here's my rationale.
>
[snip]
Yuk !
This *does* compute! I mean your rationale. Thank you *very* much for
pointing this out. The ultimate result of having one Tcl_Obj* accessed
from two interps is bad enough and will definitely result in strange memory
quirks. I think I'll have to reconsider the design partly :(
My original intention was to have a very fast access to big shared
keyed-lists and/or dictionaries w/o having to copy them from string
to internal rep and vice versa constantly.
For a very big dictionary/keyed-list it is a huge performance bottleneck.
For simple scalars it is not very expensive to copy strings arround,
so using objects does not buy any benefits. Indeed.
So what to do ?
Handling complex objects as strings is very time consuming.
OTOH, using objects is tricky and can lead you to problems.
I realize now that for the general usage, the safe-way of having
string-based shared storage, as in original nsv_*, should be ok.
For some applications, however, it is handy have the object stored
in its internal rep. You just have to make sure that DupInternalRep
does a proper deep-copy and not just a shallow one as in the
case with Tcl list object.
For list objects, one would need to patch the Tcl core. I will definitely
do this for our copy, since I need a very fast shared list access.
I doubt that it would be of general interest, though. Maybe. Maybe not.
For keyed-lists/dictionaries, I'll make sure dups are real dups.
For all other objects, one can safely work with string copies internally.
> I don't think it's sufficient to check for an tclListType internalRep
> and only stringify in that case. You have to be sure that
> Tcl_DuplicateObj will create a deep copy of the object. I suspect that
> tclByteCodeType, tclCmdNameType, tclNsNameType, tclProcBodyType, and
> tclRegexpType must be stringified, not to mention Tcl_ObjTypes added by
> extensions. At best you can check for internalReps for which it is safe
> to call Tcl_DuplicateObj (tclByteArrayType, tclBooleanType, tclIntType,
> tclDoubleType, and tclStringType). I'm not sure it's worth it.
>
Well, ... partly. As I said above...
Having a shared keyed-list and/or dictionary of couple of thousands of
elements and getting/setting one or two values ocassionaly, the benefit of
having it in internal rep is *huge*. Even for simple (albeit big) Tcl lists,
the lrange, lreplace, linsert and friends would operate *much* faster.
The trick is: one must make sure, the internal object dup functions are
well-behaving. I think I can guarantee this for keyed lists
and dictionary objects (I'll double-check it again though!).
I'll have to redesign the tcl_sv with the above in mind.
So we'll be heading for a 0.1.1 version soon !
Rob, thank you again for your time and for finding this out !
Funny, but this code is couple of months in use and I
did not have any problems with it! Another proof that
datarace problems might be tricky to trace...
Oh, yes. You remember my mail to you about the dqd_threadpool?
I realized that we needed so much extra functionality added, that I
went in another direction: I 've rewritten it in Tcl completely.
Now, that was the motivation to extend the nsv with dicts/keylists
and to use objects internaly. I can send you the code if you'd
like.
Cheer's
Zoran
