On 2005.02.25, Zoran Vasiljevic <[EMAIL PROTECTED]> wrote: > If you, with every page, create new Tcl commands, yes, they will > stay in memory (interp) and never get garbage collected until this > interp is dumped. But if the connection thread is sticky, then > this will not happen, of course. I wouldn't call this a leak, though. > This is true for any other Tcl resource: channels, namespaced > variables, namespaced procedures etc... The AS garbage-collection > mechanism on those things is poor and incomplete (admit: problem > is not easy to solve w/o programmer involvement).
nscp 1> info body ns_cleanup ns_cleanupchans; # close files ns_cleanupvars; # dump globals ns_set cleanup; # free sets ns_http cleanup; # abort any http request ns_ictl cleanup; # internal cleanup (e.g,. Ns_TclRegisterDefer's) I asked for a [tdom cleanup] so we could add it to AOLserver's [ns_cleanup] backin September 2004: http://groups.yahoo.com/group/tdom/message/918 So, we DO clean up channels, and Tcl global variables in the top-level ("::") namespace, but not namespace variables -- those tend to be used differently than Tcl globals, so they generally DO need to persist between connections within an interp. AOLserver really wins by reusing interps in a pool, which is why the default of "connsperthread == 0" is important. Yes, if you want to enforce full clean-up by dumping the Tcl interp after processing each request, you could set connsperthread == 1, but then you'd lose the performance gain of having already "warmed up" Tcl interps in a pool waiting to be used. And, as I said, we recently discovered a memory leak situation when setting connsperthread != 0. > Hence: this is not a tdom leak. This is the AS garbage-collector > issue and cannot be workaround'ed by the tdom implementation. No, but tDOM could provide a way of letting AOLserver clean up tDOM-created objects. Currently, there is NO fail-proof way of doing the cleanup, which is why I asked for a [tdom cleanup] where tDOM could track what objects it's created and then clean them up when asked to. > lexxsrv:nscp 7> dom createNodeCmd elementNode junk > ::junk > lexxsrv:nscp 8> junk > called outside domNode context > lexxsrv:nscp 9> rename junk "" > > lexxsrv:nscp 10> junk > invalid command name "junk" > > Where is the problem? Do it with "string" and not "junk". Why should it behave differently based on the proc name you choose? This is a bug. > Is this what you're looking for: > > lexxsrv:nscp 12> namespace eval junk {dom createNodeCmd elementNode string} > ::junk::string > lexxsrv:nscp 13> string > wrong # args: should be "string option arg ?arg ...?" > lexxsrv:nscp 14> ::junk::string > called outside domNode context > > Or, is it something else I'm missing here? That's it. The suggestion is that by default tDOM should be creating the commands in a sub-namespace of "tdom" to avoid it polluting the caller's namespace. This would also make automated cleanup of tDOM-created objects possible. -- Dossy -- Dossy Shiobara mail: [EMAIL PROTECTED] Panoptic Computer Network web: http://www.panoptic.com/ "He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on." (p. 70) -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.