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
