On Tuesday 03 April 2001 03:25, you wrote:
> I came across this old message while going through my inbox looking for
> It looks like this is no longer an issue in 3.3.1.
> TclpThreadDataKeyInit in thread/tcl8x.c has been rewritten:
>
> NS_EXPORT void
> TclpThreadDataKeyInit(keyPtr)
> Tcl_ThreadDataKey *keyPtr; /* Identifier for the data chunk */
> {
> Ns_Tls *tlsPtr = (Ns_Tls *) keyPtr;
>
> Ns_MasterLock();
> if (*tlsPtr == NULL) {
> Ns_TlsAlloc(tlsPtr, FreeDataBlock);
> }
> Ns_MasterUnlock();
> }
>
> It now passes FreeDataBlock to Ns_TclAlloc, so NsCleanupTls will call it
> for each Tcl TLS at thread cleanup time. FreeDataBlock calls TclpFree
> on the TLS.
Right. But the problem is that TLS usually contains private user structures.
These need to be released *just before* hread exists. This is why Tcl has
introduced thread exit handlers.
In 3.3.1 thread exit handlers get called *after* the TLS data has been
freed which obviously leads to severe memory trashing and ultimately
to cores.
In Tcl 8.3.2+ the exact opposite happens, though: *first*, exit handlers
get invoked, *then* TLS storage gets blown away. Look in
Tcl_FinalizeThread() and all will be clear.
As the thing is now, there is no elegant way (AFAIK) for calling thred
axit handlers (by Tcl_FinalizeThread) and *then* releasing the TLS data
w/o embedding the Tcl_FinalizeThread() call in thread.c in
NsCleanupThread, just before the call to NsCleanupTls(thrPtr).
Unfortunately, the thread interface is "on it's own", i.e. has no
connection to Tcl module.
I'd suggest adding new AOL API functions, something like
Ns_CreateThreadExitHandler and Ns_CancelThreadExitHandler
which would then be used instead of the Tcl standard
Tcl_CreateThreadExitHandler() function. One can even make those
API-compatible to Tcl ones. so we can just #define them and all new
thread-aware Tcl extensions can be used in AOLserver by
simply recompiling them.
This would be the cleanest way I can imagine at the moment.
Maybe Jim/Kris from DCI can say something about this ?
Cheer's
Zoran
