On 09.10.12 14:18, Stephen Deasey wrote: > > If I remember rightly, the code has long been depreciated in > AOLserver, and as no one used it and it complicates the arg parsing > and locking we removed it, along with the ns_share and ns_var command. > There's Tcl wrapper for ns_var because it was trivial. > > I've created a new module nsshare which reimplements the ns_share > command using the old C code: > > https://bitbucket.org/naviserver/nsshare/overview > > Haven't put much effort into testing it, but the skeleton of the > module is ready to go, it compiles and the sanity tests work. Great, many thanks, i hope, the people asking for it will appreciate it. > I think the way to add back the -shared switch to ns_set would be to > add a new file to this module: setcmd.c, add the C code that was > removed, export an _ns_set ?-shared? ?args ...? command which, if the > -shared flag is present does it's thing, otherwise calls the > underlying ns_set command. If you want to do this, that would be > great. well, the parsing is here not a real issue, i was more concerned about thread-safety, scalability, etc. (similar to Jeff). In my opinion, if we support it, it should go into the "ns_set" command, if we don't support it (due to instability, etc.), drop it from documentation and suggest alternatives.
When i read through the change-set, the term "-persist" means actually "-shared", all ns-sets created via the tcl-interface are "dynamic", and there was a single lock per server for all (shared) ns_sets. The mutex is used for EnterSet (adding a set to an interp), "ns_set list" and all lookup operations. So, aside of checking thread-saftey of the long list of subcommands of ns_set, and cleanup-semantics/memory leaks, the code looks pretty straight forward. The single lock for all ns_set is not very scalable, reintroducting "ns_set ... -shared" would mean to slow down existing ns_set a little (checking the flag whether a lock is needed). Using a "_ns_set" capable of handling "-shared" which just calls existing "ns_set" with the unlocked semantics would not work, using a lock with for all "_ns_set" commands is not good either without modifying the existing "ns_set" semantics (one should not be able to access variables created by "_ns_set" from "ns_set"). If we check for the shared flag in "ns_set", we are essentially at the old "ns_set" implementation. I guess the driver for removing the "-persistent" flag was that we have already so many ways of handling shared vars either in naviserver or in libthread, that this additional way with the misleading name (that should be changed) was dropped. >An alternative might be to provide equivalent functionality >(order-preserving, multiple entries for keys, access by index or key or >case-insensitive key) as a new nsv subcommand, perhaps 'nsv_multiset'. Note that there are as well in libthread the keyed list commands. Serializeíng the ns_set in a nsv, and create/save it in a thread when needed, as jeff suggested in the aolserver thread seems feasible. But these approaches require some code modification in the applications... -gustaf neumann ------------------------------------------------------------------------------ Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev _______________________________________________ naviserver-devel mailing list naviserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/naviserver-devel
