[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

> 	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"

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?