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
Store tiger instance in global task context #170
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should keep g
hidden so we can refactor without breaking things. Expose it with a helper function or class method on TaskTiger? And do we need to ensure the Redis connections are closed before the child process uses it since we would be reusing the attached Redis instance from the parent process? I thought we did that somewhere but could find it with a quick search.
The Redis connection is closed before forking in |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Add a test or two and do we need to set it here also for eager tasks?
Lines 292 to 297 in f6ed7b5
def execute(self): | |
func = self.func | |
is_batch_func = getattr(func, '_task_batch', False) | |
g['current_task_is_batch'] = is_batch_func | |
g['current_tasks'] = [self] |
Good catch with eager tasks. |
This makes it easier for libraries (e.g. FlowFish) to access the TaskTiger instance to queue further tasks.
I don't like that it's importing
_internal
but wasn't sure if there's a good way to expose it, perhaps justfrom tasktiger import g
?