Am Samstag, 2. November 2002 17:57 schrieben Sie: > 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
I have observed this... > nsthreads. However, right now there isn't 100% overlap: > - Tcl_ConditionNotify is like Ns_CondBroadcast, there's no Ns_CondSignal ... add to that: Tcl_ConditionWait returns (void) so you're never sure if it returned because of being signalled or because the (optional) timer expired. > - Result codes are always checked in nsthreads and failure is never > allowed, Tcl generally ignores pthread result codes. You can't do much except to kill the process, right? > - 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. > - 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. > - There are no rwlocks, cslocks, semaphores in Tcl but these are simple > (likely not very efficient) implementations in nsthreads anyway. Correct. > - 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(). > - 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. This two are one part. Second part is the general Tcl problem when tearing down the library resources on Tcl_Finalize, in respect to threads started with Tcl_CreateThread. This is still something not solved in Tcl library and there are some discussions on that topic between myself and some Tcl core developers. I think this would be a good starting point for solving this issue in Tcl as well. But, I wouldn't make this a strict requirement. > > One approach would be to add missing features in Tcl instead of living > without in aolserver, perhaps: YES! I think the Tcl part implementation is *almost* complete. It is for sure ok for the current state, but it sure may be better. > > - Add Tcl_MutexSetName and Tcl_MutexTryLock and the underlying counters and > API to get at the counts. The Tcl_MutexTryLock is good. Counters are also good but not strictly necessary on that level. I think they can be put on top of the Tcl_Mutex interface from within the AOLserver. One can also put them underneath in the Tcl core. Depends what other Tcl core developery might say about that. > - Add a Tcl_ConditionSignal ...and some additional wrappers for Tcl_ConditionWait (Tcl_ConditionWaitEx perhaps) which would return some reason why the call returned. > - Add a Tcl_Tls, perhaps better named Tcl_ThreadSpecificGet/SetCreate with > pthread style iterative cleanup callbacks as in pthreads. > Again, the Tcl_GetThreadData does basically the same, IIRC. The only point is the cleanup, as you correctly stated. This might be little bit more tricky but not very much. > 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. > I'm really glad you like it. This (little) change could really simplify the Windows porting efforts and avoid unnecessary duplication of code. I'm curious about what other people might say about this, most notably Jeffrey Hobbs, Andreas Kupries and other Tcl core developers. Thanks, Zoran
