luke_16 added the comment:
Relating to the idea that it is not recommended to spawn a process whenever
there are already spawned threads running, which would be the case of the
server side of my example, I have to disagree. If a process is supposed to be
completely independent of the current one (no shared memory), than this should
not be a problem. Anyway, I changed the server.py module just to clear this
possible error source.
Trying to simplify the example, I moved everything to the client.py module and
eliminated the "thread spawns process" part in order to see what happens.
Actually, I don't think that that was the case because I could not see any
process being spawned when trying to connect to the server. I think that this
happens in the current MainThread.
In the new client, I'm doing exactly what I was trying to avoid, which is to
wait for the connect() method to return. Surprisingly, the problem is still
there, in a way. Let's say you start the server and then the client. The first
attempt to send something fails and the client tries to connect to the server.
All goes well with the connection, and the client starts sending stuff to the
server. If you stop the server, wait a while (or not), and restart it again,
the client can no longer send anything, and tries to reconnect again. The
connection is then successful, but immediately after that, it cannot send
anything because of a BrokenPipeError. Only after the exception is raised and
the next loop of the "while" begins, the client can send something to the
server again. If you insert a time.sleep(x) of any number of seconds inside the
scope of the first "else" (between line 26 and 38) and right after a
"remote_buffer.put('anything')", it will raise a BrokenPipeError. Only when a
new l
oop in "while" begins, then it is possible again to send something to the
server.
This makes no sense to me. There must be something wrong with it.
--
Added file: http://bugs.python.org/file46159/case2.zip
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29158>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
