>> An instance for the class “threaded_TCP_server” and a call of >> “subprocess.run(…)”. >> > And how many connections does the subprocess make?
A new TCP connection is performed with the information from the passed parameters for each call of the function “sendall”. The test command will send JSON data over these six connections then. > A full connect(), send(), close() for each output? Yes, for this test variant. > OTOH, if you are making multiple connect() calls, then OS scheduling > could result in multiple server threads running. This functionality is desired. … > Of course, you still have to use your head! … > For instance, it makes no sense to use a forking server … I would expect that the main test process will not be forked here. >> I hope that the execution of the statement “server.shutdown()” triggers >> a separation in the reported inter-process communication. > > .shutdown() stops the server from processing new connections... I hope so, too. (Additional server objects can be created in subsequent loop iterations.) How does this interpretation fit to the wording “Tell the serve_forever() loop to stop and wait until it does.” from the documentation of the class “socketserver.BaseServer”? > It does nothing for the nature of TCP streams This aspect should be fine. > I'd be tempted to convert the master and subprocess from TCP to UDP, > just to see if there is a difference. I do not want to change the data transmission technique for this use case. I suggest to take another look at a related discussion topic like “Data exchange over network interfaces by SmPL scripts” if you would prefer to review a concrete source code example instead of recognising data processing consequences from a known test algorithm. https://systeme.lip6.fr/pipermail/cocci/2019-April/005792.html https://lore.kernel.org/cocci/6ec5b70f-39c3-79e5-608f-446a870f0...@web.de/ Will it help to add a bug report in an issue tracker? Regards, Markus -- https://mail.python.org/mailman/listinfo/python-list
