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.

Reply via email to