On Sat, 29 Mar 2014 04:44:32 -0400 Terry Reedy <tjreedy@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@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.