Nuke calls close in GUI mode to free up memory. I never noticed calls to close() during render. BTW. Some time ago I mentioned here about my problems with fetchMeta in reader class. I tested it extensively and my final conclusion was: never ever rely on open(). In my case typical scenario was as follows: Nuke occasionally create 2 instance of Op, one "main" and one "ghost" (ghost one is created probably by copy or assign constructor). Then Nuke calls open() to one of them and starts calls engine() to second one (or vice versa) while the "ghost" was automatically freed up just before. This happens in case of readers but I guess, that this could ocasionaly happens for other Ops as well.
Best Adrian W dniu 2011-05-11 20:27:21 użytkownik John <[email protected]> napisał: > Thanks for making me question my assumptions - something totally > different was going on. First I used Moritz's engine() counter trick to > convince myself that there were never any engines() running during > _open() or _close() or _validate(). Then I figured out my stupid mistake > - I was doing something along these lines : > > _open() > { > if( hash() == m_dataHash ) > { > // data is up to date > return; > } > // this will take a while > createData(); > m_dataHash = hash(); > } > > engine() > { > useData(); > } > > _close() > { > destroyData(); > } > > The problem was that occasionally Nuke would close() an Op, and > destroyData() would be called. Then Nuke would open() again, but with an > identical hash to before, so my _open() function would early out, > exposing engine() to faulty data. So the test in _open just needed to be > something like ( hash()==m_dataHash && haveData() ) instead. > > This behaviour does seem pretty unfortunate though - it means that > fairly often data gets ditched, only for the exact same data to be > recomputed a short time after. Does anyone have any opinions or insights > into this? Is it best to simply never destroy data in _close(), but > instead destroy old data in _open()? Is there a good reason for Nuke to > close() something that it intends to open() in exactly the same state > shortly after? > > Cheers... > John > > > On 05/11/2011 10:28 AM, John wrote: > > I'm not sure at all, but I was guessing based on an engine() call > > seeing a state (in terms of my member data) that I'm pretty sure > > should only be possible during _open(). In _open() I'm setting up some > > data used by the engine(), but I'm hitting the odd engine call where > > that data isn't valid - it's in a state that I think implies that > > _open is in mid flight. Rather than thinking that engine() was getting > > called before _open() I was guessing that in some circumstances > > _open() might be called again before all the previous engine() calls > > had returned. > > > > Alternatively, I could be stuffing something up. > > > > Thanks for the tips...I'll do some more digging... > > Cheers... > > John > > > > On 05/11/2011 09:18 AM, Jonathan Egstad wrote: > >> When you say concurrently - how are you sure? > >> _open() is called single-threaded from the main thread before the > >> engine threads are even spawned so it would be very strange for > >> engine threads to exist before open() is complete. > >> > >> Is it possible you're seeing a second process working on > >> postagestamps? Try starting nuke with -n to avoid this. And try > >> various thread settings like -m 0 (no engine threads) and -m 1 (only > >> one engine thread) to track this down. > >> > >> -jonathan > >> > >> On May 10, 2011, at 5:10 PM, John wrote: > >> > >>> Sorry to dig up this old thread but did anything come of this? I > >>> might be wrong but I think I'm seeing a situation where _open and > >>> engine are being called concurrently - am I right in thinking that > >>> this too is not expected behaviour? > >>> Cheers... > >>> John > >>> > >>> On 12/09/2010 04:15 AM, Abigail Brady wrote: > >>>> I'd consider it to be a bug in nuke if it calls _validate or _request > >>>> on an Op which has an ongoing engine call. I wouldn't be surprised if > >>>> there were corner cases where this happened. Reproduction steps would > >>>> be useful. > >>>> > >>>> On Thu, 09 Dec 2010 11:50:30 +0100, Moritz Moeller > >>>> <[email protected]> wrote: > >>>>> I always assumed the call order in Iops was > >>>>> > >>>>> 1. _validate() > >>>>> 2. _request() > >>>>> 3. n * engine() > >>>>> 4. wait until all engine()s have exited, then go back to 1. (if > >>>>> sth. has > >>>>> changed) > >>>>> > >>>>> I keep tabs on running engine()s using a counter class whose > >>>>> constructor > >>>>> increases a variable in the parent class and whose destructor > >>>>> decreases > >>>>> it. This way I can reliably check if all engine() threads have > >>>>> finished > >>>>> resp. no engine is running as this simply means the counter is zero. > >>>>> > >>>>> Now I check the counter in my debug build, using an assertion, inside > >>>>> _validate() and _request(). > >>>>> > >>>>> To my surprise I now found a situation where this counter is > >>>>> sometimes > >>>>> nonzero inside _validate(). > >>>>> > >>>>> Before I describe the script that triggers this: should this even be > >>>>> possible? > >>>>> I.e. should _validate() /ever/ be called while engine() threads are > >>>>> running or am I up against a potential bug here? > >>>>> > >>>>> > >>>>> .mm > >>>>> _______________________________________________ > >>>>> Nuke-dev mailing list > >>>>> [email protected] > >>>>> 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 > >> _______________________________________________ > >> Nuke-dev mailing list > >> [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 > > > > > _______________________________________________ > Nuke-dev mailing list > [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
