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 loop 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.
|