Am 02.11.14 20:05, schrieb Andrew Piskorski: > Excellent, thank you, Gustaf! > > When you get a chance, can you say a bit more about how it works? the implementation of the nsv-commands in NaviServer differs from AOLserver, by using LockArrayObj(), which uses the internal representation of Tcl_Objs for caching the arrayPtr if possible.
> Before calling Tcl_DeleteHashTable() > to remove the nsv array, you do something interesting with BucketIndex() > and an extra round of locking. Is that due to some new feature that > AOLserver did not have, maybe the mutex timings? nsv-arrays use two hash-tables, one "outer" for array names and one "inner" for the values of the array. Since this structure is kept in the Array structure, which is locked and has to be freed, i tried to avoid accessing freed data element. So i implemented a second bucket lookup for deleting the array name entry, and used the factored out function BucketIndex() to avoid code duplication. However, after sleeping over the code, the second lock can be avoided by separating the cleanup of the name-entry from the actual freeing of the array structure. https://bitbucket.org/naviserver/naviserver/commits/c82d84fdc723af4c131bd3557dc63fb5bd1fb54a > E.g., what is the clientData for exactly, and why do some functions > need to use it but others do not? The clientData of all Tcl_ObjCmdProcs is the value specified when a Tcl command is registered via Tcl_CreateObjCommand(). NaviServer (and AOLserver) pass to all commands the extended Tcl interpreter structure, namely NsInterp, which contains the NsServer and various other information for adps or connections. Some functions need to access this information, other ones don't, but every command has it set. -g ------------------------------------------------------------------------------ _______________________________________________ naviserver-devel mailing list naviserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/naviserver-devel
