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

[Jim Davidson]

In a message dated 11/2/02 3:49:36 PM, [EMAIL PROTECTED] writes:

> - Mutexes in nsthreads have string names and use counters allowing lock
> contention monitoring which you can see with "ns_info locks" (very useful).

I like this feature of ns_lock because it gives you some insight what is
happening in terms of hot-spots in the code. This part would mean rewriting
some mutex handling code in Tcl. I'd say, this can be done without adding
anything to Tcl. It can be left within the AOLserver as is now. Only the
basic lock/unlock/trylock should be delegated to Tcl code.

Yes - you could certainly leave the counters in nsthreads and just use the Tcl_Mutexes.  However, I think getting the counters in Tcl would be useful - I'm curious about a few locks already, e.g., "preserveMutex" and maybe "obsoleteFsHookMutex". In prior versions of aolserver the roles were reversed, i.e., Tcl sync objects were implemented with nsthreads and locks with highest lock contention (highest but still not alarming) were always buried in the Tcl core. 

> - There is no Ns_MutexTryLock in Tcl.

I do not know why. Both Pthreads and Windows (TryEnterCriticalSection)
allow for this. So, why there is no Tcl_MutexTryLock? I don't know.

Turns out TryEnterCriticalSection wasn't avail in older Win32 - I can't remember when it arrived but I think it was a service pack to Win2000.   The old nsthread win32 code (thread/win32.cpp in the as3.4 source) implemented it's own mutex which wasn't recursive and supported a try lock.  BTW:  I believe win/tclWinSock.c has a deadlock at line 280 with the extra SocketsEnabled check which is masked by the recursive critical sections so that needs to be fixed as well.  I used to patch that code when Tcl 8.3 was distributed with aolserver.

> - There is no Ns_Tls interface, instead the
> Tcl_GetThreadData/Tcl_CreateThreadExitHandler is used.

Looking at tls.c I see no difference to Tcl_GetThreadData, except
how the data is released during Tcl_FinalizeThread().

Well, it's true Tcl_GetThreadData calls pthread_key_create but the cleanup callback is always null.  I think my last message discussed why I believe this is a more important distinction than it may first appear, in particular the iterative cleanup not only lends itself to cleaner code but in some case (e.g., the Tcl thread allocator) it's a requirement.  I believe the people who worked on the pthread spec came to the same conclusion.  Note that Win32 Tls doesn't support iterative cleanup but the old nsthreads API implemented it and could be used for Tcl.


-Jim