John, I've always found that logging the exact millisecond time, the task ID, and the routine to a common log file using thread-safe text file writing is extremely helpful. Then you know exactly what routine was run in what thread at what exact time, and you can determine precisely what happened.
Steve -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of John Sent: Wednesday, May 11, 2011 10:29 AM To: Nuke plug-in development discussion Subject: Re: [Nuke-dev] _validate called while engine()'s is/are running 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 (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 [email protected], http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev
