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

Add a way to control process respawn. #301

Closed
wants to merge 1 commit into from
Closed

Conversation

almet
Copy link
Contributor

@almet almet commented Oct 31, 2012

The watchers now have a "respawn" option (True per default) which can be set to False. This allows to have processes that are run only once and not respawned automatically.

supersede #162.

@@ -343,8 +346,12 @@ def reap_processes(self):
self.reap_process(pid)

@util.debuglog
def manage_processes(self):
""" manage processes
def manage_processes(self, respawn=False):
Copy link
Member

Choose a reason for hiding this comment

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

you are changing the existing default behavior here, right ? Shouldn't we have True as the default value ?

Copy link
Contributor

Choose a reason for hiding this comment

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

this arg was initially named force_respawn, but it didn't feel right, and we didn't find a better name...

self.respawn (on a watcher) is True by default, so the default behavior remains unchanged: if self.respawn, then (re)spawn processes if needed.
However, if self.respawn is False, then check if the arg is True, and in this case only, (re)spawn the processes.

If the watcher.respawn is False, then processes should only be (re)spawned when explicitly asked (on a start() for example), not on each call of manage_processes (which is called periodically).

So, I guess this boils down to: what should the name of this argument be, to make it clear? Is force_respawn better?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Nope, we're not, maybe should we stay with the "force_respawn" name, which will make things more explicit.

We shouldn't need to have a look at the docstring nor the implementation to understand what this is doing. I propose that we change it back to force_respawn.

@almet
Copy link
Contributor Author

almet commented Nov 1, 2012

Updated with your remarks.

@tarekziade
Copy link
Member

@ametaireau I still see the respawn option as being True in some spots and False in others

@tarekziade
Copy link
Member

Following up an IRC discussion. I think we have a vocabulary & complexity problem here. I don't understand why we need two different options here (respawn & force_respawn) It looks over-complex at first sight.

If we are creating "single-shot" watcher, they should be specific watchers with their own internal behavior, and the controller and arbiter should work with them the same way they do with the usual one.

Maybe we need a level of inheritance to clear up and simplify this feature.

But as it stands I am lost in the code and I should not be

@@ -344,8 +347,7 @@ def reap_processes(self):

@util.debuglog
def manage_processes(self):
""" manage processes
"""
""" manage processes. """
Copy link
Member

Choose a reason for hiding this comment

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

nitpick, if we want to go all the way to PEP8, we need to start with an uppercase and remove spaces:

"""Manage processes."""

Copy link
Contributor Author

Choose a reason for hiding this comment

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

thanks, updated.

@tarekziade
Copy link
Member

o/wise LGTM

The watchers now have a "respawn" option (True per default) which can be set to False. This allows to have processes that are run only once and not respawned automatically.
@magopian
Copy link
Contributor

magopian commented Nov 5, 2012

LGTM!

@almet
Copy link
Contributor Author

almet commented Nov 5, 2012

merged.

@almet almet closed this Nov 5, 2012
@sphuber sphuber deleted the disable-process-respawn branch October 23, 2022 12:46
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

3 participants