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
