-
Notifications
You must be signed in to change notification settings - Fork 17
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
worker: add a command line argument to run task in a separate process #74
base: master
Are you sure you want to change the base?
Conversation
I will add a few tests. |
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.
We should check if signal handlers are inherited in the child process. If they are inherited, we should clear some of them. If not, we should define some of them again.
We should also kill the child process
- when heartbeat error is detected in parent (SIGHUP)
- when parent receives SIGUSR2 to drop current task.
Which signals should child process handle other than default? I guess the only one is USR1 and it is inherited from parent. I set other signal(SIGINT, SIGTERM, SIGHUP, SIGUSR2) handlers inherited from parent process, to defaults. According to signals manual, all of these signals have a default to termination. I think it is okay now, but can't wait to have your feedback. |
Have you verified that signal handlers are inherited in the child process? I couldn't find that information in Python documentation so I've written a small program to test that: https://gist.github.com/cenkalti/17a3d518b8456cff308ff644fcd0b8b5 If my test is correct, signal handlers are not inherited in the child process. These tasks still remain:
|
0a7ac3e
to
e01d81d
Compare
For the record: signal handlers are not inherited on child processes created with I believe we should make reliable changes that works on each of these operation systems. In that case, what we can do is spawning a new process, pass some shared resources to it and let it create its own resources. That I tried today but couldn't figure out some errors.
That is because Will investigate tomorrow. |
Some ideas, For the sake of simplicity, we can only target Python 3.8 on Linux. For the exception serialization problem; before raising the exception in child, we can catch it and try to pickle it before re-raising it. If we get a pickle error, we can wrap the exception and store the original exception as a string. |
To prevent any misunderstanding, the exception above happens when we launch child process. So it tries to pickle a thing (probably the "task" given in the parameters) and moves it to the child process, then restore it. That way we can have task object in child process. Also I agree with simplicity approach, we can target specific operating systems for this feature only. |
Sorry for the misunderstanding. Now I understand the unpicklable object is the Task instance. We can move the importing of the task into the child process but that would break the backwards compatibility since that task object is also used in signals. Another option would be instead of passing the task object, we can pass the module and the function as a string and reimport the task object inside the child process. I think the better approach is making the Task class picklable by overriding |
I tried to make |
No description provided.