-
Notifications
You must be signed in to change notification settings - Fork 205
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
ExecutableNode Process support #1671
Conversation
Seems like an odd test to have failed on gcc 5 only
|
So I guess its now possible to monitor an executable, but we haven't exposed any monitors that do so? What did you have in mind for such a monitor? |
I don't have any particular use cases for executable monitoring (maybe dispatcher debugging?), but I think as a general principle we should allow monitoring of any type of node process. Really, the main benefit right now is having the automatic substitutions... |
These operate by using the current context to call the existing virtual implementation methods appropriately. The Task class has also been modified to replace the stored ExecutableNode with a TaskPlug. This has the following benefits : - Consistency with context management in the rest of the API. The context is now supplied implicitly by `Context::current()` rather than explicitly by arguments to the public methods. This makes for easier coding when performing several operations in the same context. It also fixes an API flaw spot whereby ExecutableNode clients were expected to not only make their context current, but they also to pass it to the ExecutableNode methods explicitly. This was easy to get wrong, either by omitting the context scoping or by passing the wrong context to the methods. - Consistency with the ValuePlug API, which also hides all calls to internal ComputeNode methods. - Nodes will be able to have more than one output task in the future. The ExecutableNode virtual interface is now considered protected, and several methods are deprecated, but this is fully backwards compatible with the old interface.
Also use new TaskPlug API in preference to "protected" ExecutableNode API.
This makes it possible to monitor using a custom Monitor subclass. It also means that string plugs are automatically substituted during execution, relieving ExecutableNode implementations of the responsibility of doing that manually, and fixing numerous bugs where they weren't. Fixes GafferHQ#887.
2faa905
to
587faee
Compare
I've split out the removal of the manual string substitutions into #1674, so that can be merged for a future major version, and this can be merged now. |
ExecutableNode Process support
This was broken by GafferHQ#1671. Although automatic substutions are generally a great thing, in this case they were not.
This was broken by GafferHQ#1671. Although automatic substutions are generally a great thing, in this case they were not.
This does the following :
I think it's important that we do this, as it puts the ExecutableNode on a much better footing alongside the rest of our APIs, and #887 is the cause of numerous bugs (some of them yet to be discovered). It'd be great if we could go a bit further and actually break compatibility to get things really tidy, but I haven't done that here since we were hoping for 0.23 to remain the major version for a while.
It's important to note that although substitutions are now automagic, that is only the case if you use the TaskPlug API instead of the deprecated "protected" API to execute nodes (since I removed the manual substitutions). I've updated all Gaffer's code so this is the case, but there may be other code calling
ExecutableNode::execute()
directly rather than via a dispatcher (in Caribou perhaps?). If we're concerned about that, then I can split the removal of manual substitutions out of this PR, and put it into one we merge at a later date.