Checking network input processing by Python for a multi-threaded server
dieter at handshake.de
Tue Apr 30 02:12:09 EDT 2019
Markus Elfring <Markus.Elfring at web.de> writes:
> I constructed another multi-threaded TCP server for my needs
> (based on the available software documentation).
> elfring at Sonne:~/Projekte/Coccinelle/janitor> time /usr/bin/python3 list_last_two_statements_from_if_branches-statistic-server3.py
> "return code"|"received records"|"command output"|incidence
> real 1m23,301s
> user 0m6,434s
> sys 0m1,430s
> * How should this data processing approach be adjusted so that the same number
> of records will be handled in a consistent way?
Does this mean that the second number in a listing like the above
should be approximatively equal?
Then, obviously, your threads must communicate among themselves
and wait in case they have too much run ahead.
Python by itself does not garantee a fair scheduling of threads
(and of course knows nothing about the number of processed records).
It runs a thread for a number of instructions or until it releases
the so called "GIL" (= "Global Interpreter Lock") volontarily (which
it typically does when it waits or starts a typically "longer" low
level operation (such as reading from a file)). Then it
gives another thread a chance. When I remember right, then
the underlying C library decides which other thread starts.
This would mean that the level of fairness is determined by
the C library.
> * Which challenges from inter-process communication should be taken better into
> account for the involved programming interfaces (because of multi-threading)?
Multi-threading is "inner-process" not "inter-process".
As you say to have created a "multi-threaded TCP server", I assume
that your server spawns a thread for each TCP connection.
Then, you can concentrate on proper multi-thread synchronization
and forget about "inter-process communication challenges".
More information about the Python-list