On 2007.02.28, John Buckman [EMAIL PROTECTED] wrote:
Therefore, I highly recommend adding a
$doc delete
to manually delete any tdom objects you create.
At AOL, the idiomatic code for handling tDOM often looks like this:
set doc [dom parse $xml]
if {[catch {
# ... do stuff with
tdom can do automatic deleting, but it has some strict limitations.
If you pass a variable name to dom parse, as in
dom parse $xml doc
foreach n [$doc selectNodes ...] ...
then the dom object will automatically get cleaned up when the variable
doc is unset, as on return from a proc. It
Nick Miller wrote:
Heya,
I have added:
foreach lostdom [info commands domDoc0*] {
$lostdom delete
}
As you say though, best to make sure you catch them when your dealing
with them and explicitly delete them.
Thanks
Nick
Having run into this same problem before I did something similar,
Don't you open yourself up for a race condition if that code is in a
scheduled proc?
On 2/28/07, Jeff Rogers [EMAIL PROTECTED] wrote:
Nick Miller wrote:
Heya,
I have added:
foreach lostdom [info commands domDoc0*] {
$lostdom delete
}
As you say though, best to make sure you catch
Nathan Folkman wrote:
Don't you open yourself up for a race condition if that code is in a
scheduled proc?
If it was an aolserver scheduled proc then yes, but in my application it
was running in an after rescheduling loop within tclhttpd so there was
no risk of pre-emption; but the memory
I believe ns_ictl is what you would want - ns_ictl oncleanup I believe.
Another option is to run all request through a configured start page and
to put the cleanup code in that .adp page. Nice thing about that approach is
that you can make changes without having to restart the server.
Cool.
BTW, I wouldn't call this a leak, and would instead call it misuse of tDOM.
;-)
On 2/28/07, Jeff Rogers [EMAIL PROTECTED] wrote:
Nathan Folkman wrote:
Don't you open yourself up for a race condition if that code is in a
scheduled proc?
If it was an aolserver scheduled proc then yes,
