> Was it somewhere in AOLserver code? If yes, do you mind opening
> a bug report so we can fix that?

http://sourceforge.net/tracker/index.php?func=detail&aid=745784&group_id=315
2&atid=103152

> I understand that by "manipulating large local variables in memory"
> you mean variables local to the connection interpreter, not AOL shared
> variables (arrays).

Correct.  These variables are typically created within the connection
script by commands like:

set foo [someproc someargs]

> You could try "ns_atclose" to fire up scripts at the end of each
connection.
> There you can devise a custom garbage-collection scheme.

Is this required to ensure that memory is reclaimed?  I had naively assumed
that Tcl/AOLserver would take care of this (that is, that variables created
within a connection or procedure would be torn down upon closure of the
connection without manual intervention).  Is this not the case?

Assuming manual reclamation is needed, I expect we would use ns_atclose and
implement a procedure which uses [info vars] to collect the names of local
variables and unset them (we will need to create an exclusion list of nsv*
variables which are never unset).  Do you forsee any problems with this
approach?

> If the nature of data is such that it can be shared among threads, you can
> try the nsv* interface, but this would require changes to your script
code.

We do use nsv* for persistent data, but I'm pretty sure that is not the
source of this problem (and is not required for the functions to which
I am referring).  I guess part of my misunderstanding is that since a
special interface/API (nsv*) is required for persistent variables, I
had assumed that other variables would not persist.


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