When using proc = Popen() with the parameter "shell=True", the returned
proc-object's Process ID (PID) obtained by reading "proc.pid" is the
one of the shell that was created.
This gets very cumbersome, when the newly created process shall be
signalled later on.
It is very rare that one needs to signal the shell instead of the newly
started executable.
Moreover, sending a signal to the shell does (for some reason) not get
propagated to the child (=the executable/command), so the shell is quit/
terminated/killed/whatever and the command's thread is kept alive.
Using 'shell=False' is not an option in case the originating process
has more code to execute, e.g. in order to communicate with the newly
started process via pipes (i.e. using proc.stdout.readline() or
similar), because in that case Python uses os.execvp() for the command,
which re-uses (and therefore blocks) the current thread of control in
which the Popen was issued.
Starting another thread with fork() is also not an option, as the Popen
will be executed in a different thread, which makes it difficult to
pass the reference to the proc-object back into the original thread
where it is needed for the inter-process-communication.
All examples I found on the net which use pipes to communicate between
current and newly started command use of course 'shell=True', I did not
however find any simple way to get the child's PID (aside from issuing
a 'ps --ppid <PPID> -o pid=' and reading it's output, as I did, which
is far from elegant).
So, there should be one of these alternative possibilities/behaviours
in case of 'Popen(...,shell=True...)':
1) proc gets a new field or method child_pid/child_pid() which returns
the command's PID. proc.pid behaves as before
2) Signalling the shell's process notifies all children with the same
signal. proc.pid behaves as before
3) proc.pid returns the command's PID (instead of the shell's)
4) There is some simple command to query all the childs PIDs of a
process when passing in the PPID (parent PID). proc.pid behaves as
before
...with 1) being the most up to 4) being the least desireable.
I hope I did not overlook any such possibility, but searching around on
the net and in the tracker turned up nothing useful.
I really do think this should be more intuitive.
|