This is not necessarily the current version of this TIP.This is not necessarily the current version of this TIP.
| TIP: | 10000 |
| Title: | Dummy Proposal for Testing Editing Interfaces |
| Version: | $Revision: 1.100 $ |
| Authors: |
Don Porter <dgp at users dot sourceforge dot net> nobody at nowhere dot com Andreas Kupries <akupries at westend dot com> Donal K. Fellows <fellowsd at cs dot man dot ac dot uk> Andreas Kupries <a dot kupries at westend dot com> dgp at user dot sourceforge dot net Richard Suchenwirth <richard dot suchenwirth at kst dot siemens dot de> Kevin B KENNY <kennykb at acm dot org> Jeff Hobbs <hobbs at users dot sourceforge dot net> Test User <test at example dot com> New User <newbie at example dot com> Working User <thisworks at example dot com> Vince Darley <vincentdarley at users dot sourceforge dot net> Fabrice Pardo <Fabrice dot Pardo at l2m dot cnrs dot fr> |
| State: | Draft |
| Type: | Informative |
| Vote: | Pending |
| Created: | Sunday, 03 December 2000 |
This proposal has no content. It exists only to provide a document on which testing of and practice using of the TIP editing interfaces can take place.
This document serves a purpose similar to the Graffiti page (http://purl.org/thecliff/tcl/wiki/34.html) at the Tcl'ers Wiki (http://purl.org/thecliff/tcl/wiki/).
It will also be useful for testing the web editing interface proposed in TIP #13.
Joe - Here's the new proposal ----
This TIP proposes a new flag in the Tcl hash table API in support of a proposed rework of thread-specific data on the Windows platform.
The Tcl hash table constructor, Tcl_InitCustomHashTable, provides a reasonably flexible means of creating a hash table that is managed by the application. It allows for custom procuedres to calculate hash values for keys, to compare keys for equality, and to allocate and free hash table entries.
It always, however, allocates the hash table itself by means of ckalloc and ckfree. This use of Tcl's main allocator is normally not a problem, but a recent application of custom hash tables has exposed the need, from time to time, of using the system allocator (TclpSysAlloc and TclpSysFree) directly.
The motivating problem is that thread-specific data on certain versions of Windows is limited to only a small number of blocks per process (64 on at least one version). The proposed fix, which Joe Mistachkin is pursuing, involves replacing the system calls for managing thread-local storage with calls that manage the thread-specific data blocks in a per-thread hash table.
Reviewing and testing the change revealed an unfortunate circular dependency. A call to Tcl_CreateHashTable would attempt to allocate the array of hash buckets by a call to ckalloc - which translates to TclpAlloc. On a threaded build, the first thing done in this routine is to retrieve the allocation cache via TclpGetAllocCache. This in turn, once we avoid the use of TlsAlloc, winds up trying to create a thread-specific data block to hold the allocation cache. The new thread-specific data manager in turn must allocate a hash table for the thread-specific data blocks. The outcome is endless recursion.
The fix for the problem is simple - have either the allocation cache, the thread-specific data hash, or both, allocated off the system heap rather than the thread-specific allocation cache. Unfortunately, Tcl_InitCustomHashTable provides no way to accomplish this.
The flags word in the Tcl_HashKeyType data structure shall be augmented with an additional value, TCL_HASH_KEY_SYSTEM_HASH. If this bit is set in the structure passed to Tcl_CreateHashTable, then all memory allocated internally to manage the hash keys shall be obtained via direct calls to TclpSysAlloc, TclpSysRealloc, and TclpSysFree rather than Tcl_Alloc, Tcl_Realloc and Tcl_Free.
The authors considered and rejected the alternative of advancing TCL_HASH_KEY_TYPE_VERSION and defining in the structure three new function pointers to allocate, reallocate, and free memory blocks. The additional complexity (and associated performance degradation) associated with dealing with two structure versions appeared to be unnecessary; it is difficult to imagine a situation where any allocator other than the system allocator or Tcl's own will be desired for the 'buckets' array, which varies widely in size. Custom small-block allocators make much more sense for the hash values than they do for the table of hash buckets.
An implementation of this change is available from the SourceForge patch manager as item 731356. It is part of a larger overhaul of the thread-specific data manager for Windows.
This document is placed in the public domain.
This is not necessarily the current version of this TIP.