Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fixed bug with the Catalogue AsynchronousSaver #2621

Merged
merged 2 commits into from Jun 21, 2018

Conversation

andrewkaufman
Copy link
Contributor

I experienced this issue during my documentation revamp, where the screengrab app is now loading multiple scripts which use Catalogues, all within a single session. A Catalogue which had been removed from the script was still trying to save images, despite the file it wanted to write being dependent on the script variables. We now prevent saving in this obscure case.

Note that while I didn't change CatalogueTest.testDeleteBeforeSaveCompletes here, as best I can tell it isn't doing what it claims. The async save happens so quickly that the save completes before the catalogue is deleted (confirmed via prints inside the saver), so I've taken an alternate approach in my new test case.

Copy link
Member

@johnhaddon johnhaddon left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice one tracking this down Andrew. I think there's a good chance this will also fix a problem Alex was seeing...

// the saving will eventually error, so we return null instead.
// Its likely this only occurs while the node is in the process
// of being deleted (perhaps inside python's garbage collector).
if( !client->ancestor<ScriptNode>() && Context::hasSubstitutions( fileName ) )
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this would be better done in generateFileName() itself, so the fix applies everywhere it might be used, and so AsynchronousSaver doesn't need to know anything at all about how the filename is generated. generateFileName() can just return "" in this case, and then we'll hit the existing early-out above.

@andrewkaufman andrewkaufman force-pushed the catalogueLifetime branch 2 times, most recently from 7ef6f3e to 724ac59 Compare June 20, 2018 19:34
@andrewkaufman
Copy link
Contributor Author

I squashed that change in and rebased on master

@johnhaddon johnhaddon merged commit e2c45fb into GafferHQ:master Jun 21, 2018
@andrewkaufman andrewkaufman deleted the catalogueLifetime branch June 21, 2018 16:16
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants