Are you relying on the clean up in close() or the destructor as it appears the example does this in the destructor and doesn't bother with close.
-- Colin Doncaster Peregrine Labs http://peregrinelabs.com On 2012-05-23, at 2:02 PM, Jonathan Egstad wrote: > I should clarify - Reader destructors do get called (as opposed to Op > destructors) after a few seconds of idle time when Read::close() gets called. > > Unfortunately this same close() mechanism doesn't appear to happen with > DeepRead nodes... > > -jonathan > > On May 23, 2012, at 10:50 AM, Steven Booth wrote: > >> Yes, I was dealing with the same problem last week with a node that >> allocates some frame buffers for internal optimization. Nuke is currently >> very lazy about destroying Ops, it would appear. I suspect it has something >> to do with the new caching algorithm. My solution was to do my own object >> management, and when I no longer need the object, I manually delete it. >> >> Steve >> >> >> -----Original Message----- >> From: nuke-dev-boun...@support.thefoundry.co.uk >> [mailto:nuke-dev-boun...@support.thefoundry.co.uk] On Behalf Of Jonathan >> Egstad >> Sent: Wednesday, May 23, 2012 10:30 AM >> To: Nuke plug-in development discussion >> Subject: [Nuke-dev] DeepReader destructor >> >> I've written a custom DeepReader that reads a facility-specific deep file >> format and am getting high memory use due I think to the DeepReader >> destructor never being called. >> >> Like the dtexReader in the NDK examples I'm destroying the external library >> instance used to get the deep data in the destructor and rely on this to >> release the external library's memory. >> >> Am I missing something? Has anyone else seen this? >> >> Thanks, >> >> -jonathan >> >> _______________________________________________ >> Nuke-dev mailing list >> Nuke-dev@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ >> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev >> (CONFIDENTIALITY NOTICE: The information contained in this email may be >> confidential and/or privileged. This email is intended to be reviewed by >> only the individual or organization named above. If you are not the intended >> recipient, or an authorized representative of the intended recipient, you >> are hereby notified that any review, dissemination or copying of this email, >> or the information contained herein is strictly prohibited. If you have >> received this communication in error, please notify the sender by return >> email and delete this email from your system. Thank You.) >> >> _______________________________________________ >> Nuke-dev mailing list >> Nuke-dev@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ >> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev > > _______________________________________________ > Nuke-dev mailing list > Nuke-dev@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ > http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev
_______________________________________________ Nuke-dev mailing list Nuke-dev@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev
