[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