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
