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