Skip to content

Conversation

reyoung
Copy link
Collaborator

@reyoung reyoung commented Oct 13, 2017

No description provided.

dzhwinter
dzhwinter previously approved these changes Oct 14, 2017
Copy link
Contributor

@dzhwinter dzhwinter left a comment

Choose a reason for hiding this comment

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

LGTM.
NOTE. After discussed with @reyoung , I think that run_once operator can be replaced with an if-else condition operator.
We can leave that substitution work in the future.

Copy link
Collaborator

@wangkuiyi wangkuiyi left a comment

Choose a reason for hiding this comment

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

If an operator is supposed to run once, it can just maintain a data member bool has_ un_. I don't get it why we need a base class RunOnceOp.

Also, how should we set the parent class of RunOnceOp -- OperatorBase or OperatorWithKernel?

framework::OpAttrChecker* op_checker)
: framework::OpProtoAndCheckerMaker(proto, op_checker) {
AddAttr<bool>("run_once",
"whether that operator run only once or run multiple times")
Copy link
Collaborator

Choose a reason for hiding this comment

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

Given that the basic class has been named RunOnce, of course, it runs only once. How should we have such a flag that is conflicting with the class name?

@reyoung
Copy link
Collaborator Author

reyoung commented Oct 16, 2017

discussed with @tonyyang-svail. He says Op instance will be created on the fly. So we cannot maintain any state in operators.

Just close this PR.

@reyoung reyoung closed this Oct 16, 2017
@reyoung reyoung deleted the feature/run_once_for_initialize_related_ops branch October 16, 2017 23:14
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.

3 participants