On Tuesday 03 April 2001 09:25, you wrote:
> > 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.
>
> I agree. I wasn't addressing that problem. You described two separate
> memory leaks in March. I was simply pointing out that one was fixed
> correctly in 3.3.1.
>
You're right. I was too fast with return key ;)
> > 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.
>
> Tcl_FinalizeThread does some other things besides calling thread exit
> handlers. It would be nice to actually call it.
>
Again correct. The TclFinalizeIO/Notifier are also very important.
So Tcl_FinalizeThread should be called sometimes.
But, then you must make sure that TLS are still valid at that time.
> Since FreeDataBlock is used to free all the Tcl TLS blocks, we could
> have FreeDataBlock detect whether Tcl_FinalizeThread has been called,
> and call it if it hasn't been.
First thing would be to remove the call to NsTclFinalizeThread() from
FreeData() tclinit.c. At that point TLS is already gone so it's dangerous
to leave it there.
Secondly, we could introduce an static int flag in tcl8x.c which
gets examined every time a FreeDataBlock gets called.
On first call, do the NsTclFinalizeThread() and set the flag.
All others see the flag set and skip. One would need the lock
it as well (there is Ns_MasterLock/Unlock).
Yes, this way it could work.
I'll be travelling now and I'm two days out of the office.
If you come with something workable, please report.
If you have no free tine for this, I'll do it as soon as I
come back.
Cheer's
Zoran
