On Wed, Mar 07, 2007 at 11:07:54PM +0000, Stephen Deasey wrote: > Re the laz-loading, the difference seems to be: our tracing lazy > loader works on a per-proc (or other Tcl object) level, and it tries > to be transparent to the user; whereas the Tcl pkgIndex mechanism > works at the file level, and you explicitly hook into this (although > you can automate it). > > I wasn't really interested in the laziness of the loading, but the
The somtimes large memory savings of Zoran's lazy loader are attractive if it (or some other approach) can be made robust enough to satisfy you guys. Loading many thousands of identical Tcl procs repeatedly into dozens of threads never did seem like an ideal approach... Being able to create and redefine procs on the fly (possibly only in one or some threads) is good, but 95% of the time those procs are all 100% identical across all threads and never change during the runtime of the AOLserver process. (But then you know all that, and the current memory wasting method has worked for many years, even when computers had much less memory.) I suppose that eliminating all the redundant memory usage could/should be considered an separate endeavor, especially since Zoran seems to be unhappy with the complexity of his current ttrace lazy loader. Down the road, perhaps somebody will solve the memory wastage issue for multi-threaded Tcl in general. > Ultimately, I guess we could turn the server inside-out. /usr/sbin/nsd > would become a script which package requires nsd. Just need to turn > the stuff in nsd/nsmain.c etc. into commands... That would be very cool if it's robust and of similar performance to the current architecture. For one thing, it would be very nice to be able to easily use all of AOLserver's libraries directly from tclsh. Btw, I think Jim Davidson made several, "we'd like to move in that direction" type comments on the AOLserver list years ago. I wonder if you'd hit any sticky bits with special C code stuff the AOLserver process currently does on startup, e.g. opening privileged sockets as root, then doing setuid and setgid. Probably you could make all that work somehow or other, though. I also idly wonder if, down the road, some other group might want to take your newly refactored libraries of Naviserver C code and "package require" them from some entirely different scripting language (say Lua, Scheme, or Javascript). I guess not, the Naviserver C code is probably too tightly integrated with Tcl and the Tcl C libraries to make that particularly attractive to any non-Tcl developers? -- Andrew Piskorski <[EMAIL PROTECTED]> http://www.piskorski.com/ ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ naviserver-devel mailing list naviserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/naviserver-devel
