attach() and detach() are what I was using before, but they never get called for the 'transient' Ops that are created during updates. To be clear about what's happening here, if I'm sending data from my server (which in turn receives data from a renderer) to my Op, I'll be calling asapUpdate() a lot. When this happens, Nuke sometimes creates an Op (or several) to render the image. This "transient" Op gets _validate called, but does not call attach() or detach().
attach() and detach() therefore work fine for opening/closing my server connection for the firstOp(), but not for the transient Ops, which is why I tried using the ctor/dtor instead, which is how I ended up worrying about why the dtor is not always called... Seems maybe I can't win? :) ----------------------- Anders Langlands x8382/+447789206593 ________________________________ From: Steve Booth [[email protected]] Sent: 09 July 2012 17:16 To: 'Nuke plug-in development discussion' Subject: RE: [Nuke-dev] Op destructor does not get called? Gotcha. The _close solution is going to be problematic because _close is called after every render, not just when the node is being removed. How about the ‘detach()’ method of Op? If your node is detached (which surely happens when it’s deleted), then you could safely remove the shared memory? Steve From: [email protected] [mailto:[email protected]] On Behalf Of Anders Langlands Sent: Monday, July 09, 2012 9:04 AM To: Nuke plug-in development discussion Subject: RE: [Nuke-dev] Op destructor does not get called? I'm on linux right now. It's not just on termination that I want to clean up my shared memory though - imagine if the user has a nuke open for several days, creating and deleting nodes, then they're going to rack up a huge chunk of shared memory that is not actually being used. Overriding the _close() method looks kinda promising - it seems like it's always called when the user deletes a node (I'd have to handle rehooking up the resources in case of an undo I imagine, but that shouldn't be too hard), and it looks like it gets called after the given timeout for the 'transient' nodes that sometimes get created when I'm spamming asapUpdate(). I'm seeing some strange behaviour though so this needs further investigation... ultimately neither of these things seems like a great solution. ----------------------- Anders Langlands x8382/+447789206593 ________________________________ From: Steve Booth [[email protected]] Sent: 09 July 2012 16:28 To: 'Nuke plug-in development discussion' Subject: RE: [Nuke-dev] Op destructor does not get called? Which OS are you using? Windows, Linux, or OSx? There are process-termination hooks that you can utilize in each OS. From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Anders Langlands Sent: Monday, July 09, 2012 7:46 AM To: Nuke plug-in development discussion Subject: RE: [Nuke-dev] Op destructor does not get called? Hi Steve, my buffers are allocated in shared memory by a server process that then sends data to Nuke. If I don't tell the server that my Op is no longer using the shared memory, then the server process will still hold a reference to the shm and it will never be freed (at least I think so...). What I think I need therefore is to have a hook that's guaranteed to be called when Nuke closes so I can release the resource. ----------------------- Anders Langlands x8382/+447789206593 ________________________________ From: Steve Booth [[email protected]] Sent: 09 July 2012 15:42 To: Nuke plug-in development discussion Subject: Re: [Nuke-dev] Op destructor does not get called? Also note, Anders, that nothing is left hanging. Even though your destructors are not called, all heap-allocated space associated with a process is automatically freed when the process terminates. So, when you exit Nuke, you get your memory back. Steve Sent from my iPad On Jul 9, 2012, at 5:55 AM, Anders Langlands <[email protected]<mailto:[email protected]>> wrote: I'm finding that Nuke will sometimes destroy my Op, and sometimes not. If I create half a dozen plugin nodes then delete them, maybe 2 will call MyOp::~MyOp(). Then when I quit Nuke, those destructors still won't be called. In my particular plugin I allocate ~25MB of interprocess shared memory per Op, so leaving this hanging around is a bit of a deal. Is this something to do with the undo functionality or something else that I can turn off? Is there some other hook I can use that *is* guaranteed to be called when an Op is no longer needed? Cheers, Anders ----------------------- Anders Langlands x8382/+447789206593 _______________________________________________ Nuke-dev mailing list [email protected]<mailto:[email protected]>, http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev
_______________________________________________ Nuke-dev mailing list [email protected], http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev
