On 04.10.2006, at 20:26, Stephen Deasey wrote:
Or not. I don't know...
Not. It does not have anything to do with unique names. So far I recall, the procedure context stores list of literals used in the proc. When the proc scope exits the literal table is cleaned and all literal objects are decr-ref-counted (ulimately put back on the per-thread list of free objects). I'm not SURE that this is so, I recall seeing this at the time I was chasing a very weird bug resulting in wrong usage of Tcl objects. A peek into Tcl sources will surely reval that, but even w/o that, my little example illustrates exactly such behaviour. We might need to understand how come you get different behaviour but this way or another, the objects get lost. BUT... this way or another, what you did is perfectly OK as there is no other way one can do that. It is just that people need to be aware of such possiblity and operate either on the handle of the mutex or on its name. In our code I have done the same on the Tcl level. I invented the "getlock" call which returned the mutex handle, cacheing it in between in the nsv array. You could improve the code by inventing similar bucket based locking as done in nsv in order to avoid using that one single global lock.
