On Friday 25 February 2005 17:30, Dossy Shiobara wrote:

>     nscp 1> info body ns_cleanup

This is a half-baked approach still arround from the non-namespaced
Tcl age. Attempt to clean up what you can... Sure something
not really deserving the garbage-collection name but works
sometimes... I recall several threads on the aolserver list
asking for a better garbage collector...

> 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.

They do not. It is just practically unfeasible (performace wise) to remember
all interp resources before the processing and afterwards walk arround and
see what has changed (and how) and then rectify this. This is the reason.
The real garbage-collection is a tough issue. Hence not tackled by
the AS yet. So, what's here (ns_cleanup) works but not realy universally.

>
> 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.

Ah, I think we both speak about the same thing, but use different
notation. While the connection thread lives, it holds Tcl interpreter.
All resources in this interpreter not handled by the programmer
*or* by ns_cleanup will stay until this interp gets dumped. It will
never get dumped if the connection thread never exits. And it will
never exit if connsperthread == 0. Is this what we are talking about?

> 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.

OK. This is clear. The [dom cleanup] kind of thing would be
feasible and practical. No doubt about it. I will see with
Rolf to get it in the CVS.

>
> Do it with "string" and not "junk".  Why should it behave differently
> based on the proc name you choose?  This is a bug.

You asked for it:

lexxsrv:nscp 1> rename string ""
lexxsrv:nscp 2> string
Connection closed by foreign host.

Is this a bug? The thing is: "unknown" is using Tcl string command
and you get weird output when renaming some Tcl built-in commands.
So, no [string} command in hash-table triggers unknown, which uses
[string] which is not there: bang: you blow the stack (AS) or get
this:

[EMAIL PROTECTED]:~/rel-1-5-0-branch/dev/lexxapps> tclsh
% rename string ""
% string
self-referential recursion in "unknown" for command "string"

>
> 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.

Well, this is not difficult to make. The only thing is how to
assure backward compatibility? I will discuss this with Rolf
and we will see what we can do about it...
So, basically, either [tdom cleanup] or tdom:: private namespace
or both...

--
  With kind regards,
  Mit besten Gruessen,
  Meilleures Salutations,
  ___________________________________________
  Zoran Vasiljevic, Vice President, CTO

  E-mail: mailto:[EMAIL PROTECTED]
  Web:    http://www.archiware.com
  Phone:  +49 89 319 084 98
  Fax:    +49 89 319 084 99
  S-mail: ArchiWare(R) GmbH
          Gutenbergstr. 3
          D-85716 Munich, Germany
  ___________________________________________
  PresSTORE(R) - Backup  Synchronize  Archive


--
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