I looked a little at the TCL C binding mechanism, and it seemed like that would be a good way to do ns_shares. One problem I noticed is that there is no way for a TCL var to "not exist" if it is bound to a C variable, ie, [info exists blah] will always be true for a TCL var bound to a C var, but not always true for ns_shares.
Since the TCL core already has all this stuff in it about binding TCL vars to C vars, it seems plausible to use it for ns_shares and get 7.6-like performance without needing traces. I had to look at & halfway understand the ns_share changes to the TCL 7.6 core in order to fix the "malformed bucket chain" error. I realize it's a hack to the TCL core, but it didn't seem that horrible for the benefits it yields. It didn't seem like a bigger hack than the 8x trace implementation, though I understand that the 7.6 way is part of the core and the 8x way is independent of the core. We have lots of TCL code and lots of ns_shares on our site. So aside from my philosophical dislike of nsv's, there's just too much code for us to change, both time-wise and risk-wise. IMO, an easy-to-use shared variable store is one of the greatest features of AOLServer. ns_share, to me, is the right paradigm. Maybe the TCL core guys can see their way to implementing an easy shared var mechanism that works like ns_share. I can dream... :) Jim > > On Saturday 09 November 2002 02:26, you wrote: > > Hi - this sounds interesting. Can an ns_share emulation be > > implemented on top of this new shared var mechanism with good > > performance, i.e., at least equivalent to TCL7.6 ns_shares? > > > > I doubt that we will get the function/performance of ns_share > as in 7.6. It was an entirely differen beast, as you know. > > I might design a way of getting the regular Tcl variable bound > to a shared variable under the hood, so one can get more/less > what ns_share offered. > > You'd eventually be able to do: > > tsv::share sharedVariable localVariable > > and then do something like > > set localVariable(myindex) myValue > puts $localVariable(myindex) > > in your script. This I may do with variable traces or > some other scheme, I'm not yet sure about that. > > Is the nsv_* something you cannot use as-is? > I find it very convenient. The only thing I do not > like at the moment is the need of an extra command to > access it. This would be solved by the above approach. > I must admit, I'm just playing with the idea. I did not > give it a serious thinking, though. > > Cheers > Zoran >
