Checking network input processing by Python for a multi-threaded server

dieter dieter at
Tue Apr 30 02:12:09 EDT 2019

Markus Elfring <Markus.Elfring at> 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
> "return code"|"received records"|"command output"|incidence
> 0|9||63
> 0|5||5
> 0|13||2
> 0|10||5
> 0|11||7
> 0|8||3
> 0|7||3
> 0|14||3
> 0|6||4
> 0|12||3
> 0|4||2
> 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 mailing list