On Thu, Aug 28, 2008 at 9:52 PM, Vasiljevic Zoran <[EMAIL PROTECTED]> wrote: > > On 21.08.2008, at 21:06, Stephen Deasey wrote: > >> You used to have to manually edit the makefile to disable zippy. Is >> this still the case? >> >> Perhaps the Tcl default should be to use the system allocator even on >> threaded builds, and to provide a configure switch to enable zippy. >> Zoran, you have Tcl cvs access right? > > Yes. I just discussed this with Vlad. > Here is the consensus: > > There is Tcl single-threaded allocator and zippy allocator. > > If you turn on Tcl allocator it should use > single-threaded allocator for non-thread builds > zippy allocator for thread builds > > If you turn off Tcl allocator it should use > system-level malloc regardless of the thread/nonthread builds > > This is most "logical" setup. So, either you have custom Tcl > memory allocator or not. If you dont, then system malloc is used. > If you do, then it depends on the threaded build. > > To aid this, there is (confugure-wise unused) USE_TCLALLOC define. > Control which (simple one-lock Tcl allocator or AOL's zippy allocator) > is selected, is done over USE_THREAD_ALLOC. > > By allowing the USE_TCLALLOC to be confugured "from the outside" > one can decide wether TCL allocator (singlethreaded or zippy) > or system/OS malloc us used. > > The USE_THREAD_ALLOC is implicitly set (reset) when threaded build > is configured (or not). > > This way we would have one "knob" (the USE_TCLALLOC) which we can > toggle over --enable-tclalloc (default us true). By --disable-tclalloc > we would default to system level alloc, thread build or not. > > This is the path of least resistence and would not change any defaults. > I could go to the Tcl core list with this suggestion, yes. > > Vlad suggested to raise the queston of disabling the zippy even for > thread builds, per default. I can only second that. But then again, > we would change the default behaviour from as-is now and that is a > chance to get some oposition which I do not have time to deal with. > > What do you think?
Sounds sensible. Configuration knob first, change defaults later, possibly. To change the default is going to require proof that one way is better than another anyway. There's a Tcl performance test suite somewhere, right? Some work for somebody... ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ naviserver-devel mailing list naviserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/naviserver-devel
