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

[Markus Elfring]

> 	Server.shutdown() sets a flag that tells the main server to /stop
> accepting new requests/.

Can it be that this method should perform a bit more resource management
(according to the selected configuration like “socketserver.ThreadingMixIn”)?


> 	So far as I can tell, for a threaded server, any threads/requests that
> were started and haven't completed their handlers will run to completion --
> however long that handler takes to finish the request. Whether
> threaded/forked/single-thread -- once a request has been accepted, it will
> run to completion.

This is good to know and such functionality fits also to my expectations
for the software behaviour.


> Executing .shutdown() will not kill unfinished handler threads.

I got a result like the following from another test variant
on a Linux system.

elfring at Sonne:~/Projekte/Python> time python3 test-statistic-server2.py
incidence|"available records"|"running threads"|"return code"|"command output"
80|6|1|0|
1|4|3|0|
1|4|4|0|
3|5|2|0|
1|5|3|0|
5|7|1|0|
1|3|4|0|
1|8|1|0|
1|4|1|0|
3|5|1|0|
1|4|2|0|
1|3|2|0|
1|6|2|0|

real	0m48,373s
user	0m6,682s
sys	0m1,337s


>> How do you think about to improve the distinction for the really
>> desired lock granularity in my use case?
>
> 	If your request handler updates ANY shared data, YOU have to code the
> needed MUTEX locks into that handler.

I suggest to increase the precision for such a software requirement.


> You may also need to code logic to ensure any handler threads have completed

Can a class like “BaseServer” be responsible for the determination
if all extra started threads (or background processes) finished their work
as expected?


> before your main thread accesses the shared data

I became unsure at which point a specific Python list variable
will reflect the received record sets from a single test command
in a consistent way according to the discussed data processing.


> -- that may require a different type of lock;

I am curious on corresponding software adjustments.


> something that allows multiple threads to hold in parallel
> (unfortunately, Event() and Condition() aren't directly suitable)

Which data and process management approaches will be needed finally?


> 	Condition() with a global counter (the counter needs its own lock)
> might work: handler does something like

How much do the programming interfaces from the available classes support
the determination that submitted tasks were completely finished?


> The may still be a race condition on the last request if it is started
> between the .shutdown call and the counter test (ie; the main submits
> .shutdown, server starts a thread which doesn't get scheduled yet,
> main does the .acquire()s, finds counter is 0 so assumes everything is done,
> and THEN the last thread gets scheduled and increments the counter.

Should mentioned system constraints be provided already by the Python
function (or class) library?

Regards,
Markus