M
Metalone
I wanted to use Multiprocessing.Pipe and Multiprocessing.Process to
peform Actor style communication.
However, I just can't get what I need done, and I think it is due to
inherit problems with the design of Pipe.
If I have a process like this
def process1(conn):
while True:
msg = conn.recv()
if msg == 'go':
res = go() # this is a long running function
conn.send(res) # send result back to caller
elif msg == 'stop':
stop() # this is intended to stop the go() function, for
example using deciding to abort operation.
In this code the 'stop' message cannot be received, because the code
is in the long running go() function.
So lets change it.
def process1(conn):
while True:
msg = conn.recv()
if msg == 'go':
t = threading.Thread(target=go, args=(conn,))
t.start()
elif msg == 'stop':
stop() # this is intended to stop the go() function.
Now the thread-1 is waiting on the blocking recv().
If the go() function completes on thread-2, it wants to send its
result via the connection object, but it can't because
the connection is in use.
Trying to work around this gets complicated.
For example, using a second process and a second connection object to
read the 'stop' message, and then changing a shared memory flag to
stop the go() function.
Pipes not being concurrently bi-directional appears to be a design
flaw to me.
pyCSP appears to be an interesting approach, but it does not support
communication across O.S. processes on Win32.
peform Actor style communication.
However, I just can't get what I need done, and I think it is due to
inherit problems with the design of Pipe.
If I have a process like this
def process1(conn):
while True:
msg = conn.recv()
if msg == 'go':
res = go() # this is a long running function
conn.send(res) # send result back to caller
elif msg == 'stop':
stop() # this is intended to stop the go() function, for
example using deciding to abort operation.
In this code the 'stop' message cannot be received, because the code
is in the long running go() function.
So lets change it.
def process1(conn):
while True:
msg = conn.recv()
if msg == 'go':
t = threading.Thread(target=go, args=(conn,))
t.start()
elif msg == 'stop':
stop() # this is intended to stop the go() function.
Now the thread-1 is waiting on the blocking recv().
If the go() function completes on thread-2, it wants to send its
result via the connection object, but it can't because
the connection is in use.
Trying to work around this gets complicated.
For example, using a second process and a second connection object to
read the 'stop' message, and then changing a shared memory flag to
stop the go() function.
Pipes not being concurrently bi-directional appears to be a design
flaw to me.
pyCSP appears to be an interesting approach, but it does not support
communication across O.S. processes on Win32.