[Python-Dev] Status of PEP 3145 (original) (raw)

[Python-Dev] Status of PEP 3145 - Asynchronous I/O for subprocess.popen

Antoine Pitrou solipsis at pitrou.net
Sat Mar 29 16:30:25 CET 2014

On Sat, 29 Mar 2014 04:44:32 -0400 Terry Reedy <tjreedy at udel.edu> wrote:

On 3/28/2014 5:12 PM, Antoine Pitrou wrote: > On Fri, 28 Mar 2014 16:58:25 -0400 > Terry Reedy <tjreedy at udel.edu> wrote:

>> However, the code below creates a subprocess for one command and one >> response, which can apparently be done now with subprocess.communicate. >> What I and others need is a continuing (non-blocking) conversion with 1 >> and only 1 subprocess (see my response to Josiah), and that is much more >> difficult. So this code does not do what he claims his will do. > > Why don't you use multiprocessing or concurrent.futures? They have > everything you need for continuous conversation between processes. I have not used either and no one suggested either before, while Amaury Forgeot d'Arc and Guido suggested subprocess pipes. I added those two ideas to the issue.

Looking at idlelib/rpc.py, it looks largely like an uncommented (untested?) reimplementation of multiprocessing pipes, with weird architecture choices (RPCServer is actually a client?).

multiprocessing should have everything you need: you can run child processes, communicate with them using Queues, Locks, Conditions, or you can even automate asynchronous execution with a process Pool. Those are cross-platform and use the most appropriate platform-specific primitives (for examples named pipes under Windows). They are also quite well-tested, and duly maintained by Richard :-)

Regards

Antoine.

More information about the Python-Dev mailing list