On 04.10.2006, at 11:24, Zoran Vasiljevic wrote:
I think I see where the problem is and will fix that now.
I've fixed that but this opens another discussion.
Basically you wanted to avoid using handles. Then you said,
OK, I can use string names and turn them to handles on as-needed
basis by looking them up in an internal table. Everytime this
lookup happens I need to global lock the table then lookup the
(whatever)handle using it string name.
To avoid that global lock, you change/update the object holding the
string rep with the calculated handle and you count on the fact
that next usage of the same object will avoid having to to the
(costly) lookup.
Did you think about such uses:
ns_mutex lock themutex
while {} {
ns_cond wait thecond themutex
}
ns_mutex unlock themutex
because here EVERY time you will have to lock the global
lock to get the handle of the "thing", as the "trick" to
save it in the object will not work! The "themutex" or
"thecond" could/will always be different objects if used
this way, so there is no gain.
If one however does:
set m themutex
set t thecond
ns_mutex lock $m
while {} {
ns_cond wait $c $m
}
ns_mutex unlock $m
it WILL work. But how are you going to convey this information
to the Tcl programmer??? He's implicitly serializing his app
at the place he does not expect (lookup of the internal hash
table).
I believe this is not very optimal and requires some other
"means" of hiding this information (the handle), potentially
using complete different paradigms of programming (more suitable
to Tcl way of doing things - if there is such a "way" at all).
