Re: [AOLSERVER] Use Tcl thread supprt instead of nsthread?

[Jim Davidson]

In a message dated 11/2/02 8:01:36 AM, [EMAIL PROTECTED] writes:

I've examined the nsthread library as in AOLserver 4.0 and
it seems to me that this piece of code can be re-rwritten to
use Tcl thread wrappers. This would ease the task of people
doing AOLserver ports on Windows, since most of the work
for that platform has already been done in Tcl itself.

After peeking arround in nsthread/*.[ch] I'm pretty sure that
most of the functionality can be implemented with existing
Tcl thread wrappers. Some dusty condition-variable corners
are still not handled in Tcl, but this should be relatively
easy to implement and build into the Tcl.

I would like to get some opinions from AOLserver core
developers about this issue. Would it make sense to you?
Are there some hidden problems I've overlooked there?

Hi,

Short answer is yes, shouldn't need two interfaces.  In fact, there's been some sharing of code in the past.  The idea of the master lock and dynamic initialization of mutexes and conditions in nsthreads came from Tcl and the Win32 condition code and thread memory allocator in Tcl came from nsthreads. However, right now there isn't 100% overlap:

- Tcl_ConditionNotify is like Ns_CondBroadcast, there's no Ns_CondSignal
- Result codes are always checked in nsthreads and failure is never allowed, Tcl generally ignores pthread result codes.
- Mutexes in nsthreads have string names and use counters allowing lock contention monitoring which you can see with "ns_info locks" (very useful).
- There is no Ns_MutexTryLock in Tcl.
- There are no rwlocks, cslocks, semaphores in Tcl but these are simple (likely not very efficient) implementations in nsthreads anyway.
- There is no Ns_Tls interface, instead the Tcl_GetThreadData/Tcl_CreateThreadExitHandler is used.
- Nsthread's (like other AOLserver dynamic libraries) uses a DSO load time init routine NsthreadsInit which avoids the various initialization checks..
- Tcl tracks the creation of various sync objects and nsthreads assume (for most cases) the objects live for the life of the process and DSO unload is never possible.


One approach would be to add missing features in Tcl instead of living without in aolserver, perhaps:

- Add Tcl_MutexSetName and Tcl_MutexTryLock and the underlying counters and API to get at the counts.
- Add a Tcl_ConditionSignal
- Add a Tcl_Tls, perhaps better named Tcl_ThreadSpecificGet/SetCreate with pthread style iterative cleanup callbacks as in pthreads.


A benefit of this approach would be that Tcl could then use the nsthread/pthread style thread specific data and iterative cleanup which has worked very well in aolserver.  Briefly, nsthread thread specific cleanup handlers will be called repeatedly to catch a cleanup handler reinitializing a previously cleaned up slot.  This does happen in practice - in fact the Tcl thread memory allocator exhibits this behavior.  If you add:

fprintf(stderr, "cleanup %d\n", Tcl_GetCurrentThread());

at the start of TclFreeAllocCache in tcl8.4/generic/tclThreadAlloc.c, recompile and try:

% tclsh8.4
% load /usr/local/aolserver/libnsd.so
% ns_thread begindetached {puts [ns_thread getid]}
tid0x88300
% 557824
cleanup 557824
cleanup 557824

you see this in action.  The reason the clenaup is callled twice is some later cleanup re-initializes the per-thread memory allocator so pthreads calls the cleanup again. I had to implement this directly for Tcl because the Tcl API didn't support it.  One could argue such support should be a requirement - consider Tcl_FinalizeThread in tclEvent.c - what if one of the user-supplied exit handlers re-initializes a previously cleaned up resource?  This could lead to a leak in the current implementation but would be caught by an iterative approach .

Anyway, if we updated Tcl code to support what's needed in nsthreads we could dump nsthreads. This could ease porting AOLserver back to Win32 and may benefit Tcl as well.  Seems like a good idea to me.

-Jim