>>> 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”)?
>>
> There isn't much more it can do
I see further software design possibilities.
> -- it has been a long standing axiom that killing threads is not recommended.
This data processing approach will trigger various development challenges.
>>> 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?
>
> You are asking for changes to the Python library for a use case
> that is not common.
I find this view questionable.
> Normally connections to a server are independent and do not share common data
Would you like to clarify corresponding application statistics any further?
> -- if there is anything in common,
Do you identify any more shared functionality?
> it is likely stored in a database management system
An use case evolved into my need to work also with an ordinary Python list
variable for a simple storage interface.
> which itself will provide locking for updates,
It is nice when you can reuse such software.
> and the connection handler will have to be coded to handle retries
> if multiple connections try to update the same records.
I am not concerned about this aspect for my test case.
> Servers aren't meant to be started and shutdown at a rapid rate
Their run times can vary considerably.
> (it's called "serve_forever" for a reason).
Will an other term become more appropriate?
> If the socketserver module doesn't provide what you need,
It took a while to understand the observed software behaviour better.
> you are free to copy socketserver.py to some other file (myserver.py?),
> and modify it to fit your needs.
Will it help to clarify any software extensions with corresponding maintainers?
> Maybe have the function that spawns handler threads append the thread ID
> to a list, have the function that cleans up a handler thread at the end
> send its ID via a Queue object,
This approach can be reasonable to some degree.
> and have the master periodically (probably the same loop that checks
> for shutdown), read the Queue, and remove the received ID from the list
> of active threads.
I imagine that there are nicer design options available for notifications
according to thread terminations.
> On shutdown, you loop reading the Queue and removing IDs from the list
> of active threads until the list is empty.
Will a condition variable (or a semaphore) be more helpful here?
>> How much do the programming interfaces from the available classes support
>> the determination that submitted tasks were completely finished?
>>
> Read the library reference manual and, for those modules with Python
> source, the source files (threading.py, socketserver.py, queue.py...)
>
> The simpler answer is that these modules DON'T...
I suggest to improve the software situation a bit more.
> It is your responsibility.
This view can be partly appropriate.
> socketserver threading model is that the main server loops waiting
> for connection requests, when it receives a request it creates
> a handler thread, and then it completely forgets about the thread
I find that this technical detail can be better documented.
> -- the thread is independent and completes the handling of the request.
Would you occasionally like to wait on the return value from such
data processing?
(Are these threads joinable?)
> If you need to ensure everything has finished before starting
> the next server instance, you will have to write the extensions
> to socketserver.
I might achieve something myself while it can be also nice to achieve
adjustments together with other developers.
>> Should mentioned system constraints be provided already by the Python
>> function (or class) library?
>
> Again, the model for socketserver, especially in threaded mode, is that
> requests being handled are completely independent. shutdown() merely stops
> the master from responding to new requests.
I find this understanding of the software situation also useful.
> In a more normal situation, .shutdown() would be called
> and then the entire program would call exit.
* Do you expect any more functionality here than an exit from a single thread?
* Does this wording include the abortion of threads which were left over?
> It is NOT normal for a program to create a server, shut it down,
> only to then repeat the sequence.
Will your understanding of such an use case grow, too?
Regards,
Markus
--
https://mail.python.org/mailman/listinfo/python-list
