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
Using multiprocessing module crashes parallel iPython #92
Comments
[ LP comment 1 by: Justin MacCallum, on 2010-02-05 01:15:35.441384+00:00 ] After some research, I believe that this is an issue that arises because of Twisted, which doesn't play nice with mulitprocessing or popen. |
[ LP comment 2 by: Brian Granger, on 2010-02-05 02:17:19+00:00 ] Are you using multiprocessing or just subprocess? Brian On Thu, Feb 4, 2010 at 5:14 PM, Justin MacCallum
Brian E. Granger, Ph.D. |
[ LP comment 3 by: Justin MacCallum, on 2010-02-05 02:28:03.882376+00:00 ] Sigh... sorry. It was a typo, I'm just using subprocess. I still believe my comment is valid though; I think this is a long standing problem with Twisted. |
[ LP comment 4 by: Brian Granger, on 2010-02-05 02:37:28+00:00 ] Yes, my feeling is that subprocess won't work reliably in any twisted Cheers, Brian On Thu, Feb 4, 2010 at 6:28 PM, Justin MacCallum
Brian E. Granger, Ph.D. |
[ LP comment 5 by: Justin MacCallum, on 2010-02-12 19:27:40+00:00 ] Hi Brian, I agree that the problem lies in how Twisted deals with signal handling. However, this has been a known problem with Twisted for a very long time. Unfortunately, it doe not look like fixing it is much of a priority. The usual response is that you should do things the Twisted way and use their API to spawn a process. The problem comes for projects like iPython that, ideally, shouldn't be exposing any of Twisted at all. Perhaps you might have more traction with the Twisted folks, given that you have a well known project that would benefit from fixing this bug. As I understand it, the solution is to write a simple C extension module that fixes signal handling - just no one has done it yet. I should also point out, that these problems don't exist if the calls to subprocess occur in a separate thread spawned by deferToThread. I haven't had time to look at the source, but how hard would it be to setup the engines so that remote calls are run using deferToThread? Regards, On Feb 4, 2010, at 6:37 PM, Brian Granger wrote:
|
[ LP comment 6 by: Brian Granger, on 2010-02-15 17:38:01+00:00 ]
I think your assessment is correct. When you use Twisted you have to
I don't see how deferToThread helps as the signal handlers are process wide. Cheers, Brian
Brian E. Granger, Ph.D. |
Does this issue go away with our move to ZMQ rather than twisted? |
Yes, this issue no longer applies to the new 0MQ+tornado parallel code. Closing as wontfix. |
conversion formats: pdf removed and latex added
Original Launchpad bug 517358: https://bugs.launchpad.net/ipython/+bug/517358
Reported by: justin-maccallum (Justin MacCallum).
I have a parallel scientific code that runs on clusters. It currently uses my own (badly designed) parallel communication engine and I'm trying to transition to iPython's TaskClient interface. One part of my code uses the subprocess module to wrap a call to a different piece of software. Unfortunately, this seems to be causing problems for me. I'm running on OS X 10.6.2, with python 2.6.4 and ipython 0.10 as supplied by MacPorts. The following code snippet will reproduce the problem I'm having.
The output of this program is:
The ipcontroller log file looks like:
Notice that a few of the tasks actually complete, while the majority fail with the strange interrupted system call error.
The text was updated successfully, but these errors were encountered: