Launching A Truly Disjoint Process
cs at zip.com.au
Mon Mar 12 00:04:14 CET 2012
On 11Mar2012 17:34, Dave Angel <d at davea.name> wrote:
| On 03/11/2012 05:01 PM, Ami Tavory wrote:
| > I'm encountering a problem using the multiprocessing module to create a
| > process that is truly disjoint from the parent process: i.e., one that
| > contains no "memory" of the parent process, nor any record in the parent
| > process that it is its child. This originated in a pygtk problem, but I'll
| > try to put down as little pygtk as possible - just enough to explain the
| > problem (also, sorry, but I couldn't get an answer at the gtk forum).
| > The code is a small python debugger front-end for GEdit. The plugin code,
| > run from GEdit's process, uses
| > <code>multiprocessing.Process(target = run_dbg)</code>
| > to launch the debugger in a function in separate process. The debugger uses
| > the bdb module like this:
| > <code>bdb.run('execfile("%s")' % script)</code>.
| > This seems to work fine, except if the script being debugged is itself a
| > pygtk script. Specifically, if it contains the code
| > <code>Gtk.main()</code>
| > then GEdit crashes with
| Why not try using bash as an intermediate executable? Have your first
| python process invoke bash, giving it the arguments to in turn launch
| the second python process.
Why use bash at all? That requires painful and inefficient argument quoting, etc.
Just invoke Python itself directly i.e. get subprocess to fork/exec (aka
spawn) a new invocation of Python instead of using execfile.
Totally untested prototype based purely on a cursory glance at the docs:
'import bdb; import os; bdb.run("execfile(os.environ[\"bdb_execfile\"])")',
That "import..." string is all one line. Of course various arguments to
Popen as required, etc.
Cameron Simpson <cs at zip.com.au> DoD#743
Here's a great .sig I wrote, so good it doesn't rhyme.
Jon Benger <jbenger at agravaine.st.nepean.uws.edu.au>
More information about the Python-list