> The file name for the client script is passed by a parameter to a command
> which is repeated by this server in a loop.
> It is evaluated then how often a known record set count was sent.
In which time ranges would you expect the receiving of the complete JSON data
which were sent by the child
>> I get an other impression from the statements “self._threads.append(t)”
>> (process_request)
>> and “thread.join()” (server_close).
>
> Okay -- v3.7 has added more logic that didn't exist in the v3.5 code
> I was examining... (block_on_close is new).
Thanks for such a version
> socketserver threading model is that the main server loops waiting for
> connection requests, when it receives a request it creates a handler thread,
This data processing style can be generally fine as long as you would like
to work without a thread (or process) pool.
> and then it completely
> Nowadays, I develop typically web applications.
> There, something similar to "CORBA" is used: WSDL described
> "web services". Typically, they use the web infrastructure
> and its protocols ("http", "https") for communication.
The popularity varies for these programming interfaces over time.
> Nowadays, I develop typically web applications.
> There, something similar to "CORBA" is used: WSDL described
> "web services". Typically, they use the web infrastructure
> and its protocols ("http", "https") for communication.
The popularity varies for these programming interfaces over time.
Markus Elfring writes:
> ...
> I imagine that it can be easier to depend on a higher level
> system infrastructure.
> How do you think about to reuse software extensions around
> the standard “CORBA” like “omniORB”?
I have used "CORBA" in the past. It is nice when you
control all cooperating
> And in addition, you can derive your own class from `socketserver`
> and override methods to provide whatever additional functionality
> you think is necessary.
Such a programming possibility remains generally.
I am curious if the software development attention can be adjusted
also in this
Dennis Lee Bieber writes:
> On Sat, 4 May 2019 14:17:52 +0200, Markus Elfring
> declaimed the following:
> ...
> If the socketserver module doesn't provide what you need, you are free
> to copy socketserver.py to some other file (myserver.py?), and modify it to
> fit your needs.
And in
>>> 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
> If you have a multi-threaded application and you want to be on
> the "safe side", you always use your own locks.
I suggest to reconsider your software expectations around
the word “always”.
There are more software design options available.
> Python uses locks to protect its own data
> 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
Markus Elfring writes:
> ...
> But I am more interested in the detail that a specific Python list variable
> should reflect the received record sets from a single test command
> in a consistent way.
If you have a multi-threaded application and you want to be on
the "safe side", you always use
> I suggested UDP as a TEST, not for the end use...
I can understand such a suggestion.
Can it distract from other software surprises?
> If UDP gives you the results you expect, it most likely means there is a
> problem
There is a questionable software behaviour still waiting for a
> In any multi-threaded application, you must be carefull when
> accessing (and especially modifying) shared (e.g. "global") objects.
> In general, you will need locks to synchronize the access.
I agree to this general view.
> Appending to a list (and some other elementary operations
> on
>> An instance for the class “threaded_TCP_server” and a call of
>> “subprocess.run(…)”.
>>
> And how many connections does the subprocess make?
A new TCP connection is performed with the information from the passed
parameters
for each call of the function “sendall”. The test command will
>> May I expect that data were completely received from clients and accordingly
>> processed by the request handler in the started threads after
>> the statement “server.shutdown()” was sucessfully executed?
>
> Python delegates those low level services to the underlaying
> network library, which
Markus Elfring writes:
>> https://docs.python.org/3/library/socketserver.html#asynchronous-mixins
> An example is provided also in this software documentation.
> May I expect that data were completely received from clients and accordingly
> processed by the request handler in the started threads
> Why not provide them so that anyone trying to analyze what you are
> seeing can try them for themselves.
I assume that an other information system can be more appropriate
for file distribution than this mailing list.
> Starting a full process takes time
This is usual. - Such an
> https://docs.python.org/3/library/socketserver.html#asynchronous-mixins
I have constructed a pair of small scripts for another test.
A command (which refers to the second Python script) is executed 100 times
by “subprocess.run()” with parameters so that the child process can send six
test
> https://docs.python.org/3/library/socketserver.html#asynchronous-mixins
An example is provided also in this software documentation.
May I expect that data were completely received from clients and accordingly
processed by the request handler in the started threads after
the statement
Markus Elfring writes:
> ...
>> As you say to have created a "multi-threaded TCP server", I assume
>> that your server spawns a thread for each TCP connection.
>
> Is this the software behaviour we usually get from
> the class “socketserver.ThreadingMixIn”?
Look at the source -- and there look
> Does this mean that the second number in a listing like the above
> should be approximatively equal?
The expectation (or hope) was that an identical number of record sets
would be available for each loop iteration in such a data processing approach
by the server.
But the reality is different
Markus Elfring writes:
> ...
> I constructed another multi-threaded TCP server for my needs
> (based on the available software documentation).
> https://docs.python.org/3/library/socketserver.html#asynchronous-mixins
> ...
> elfring@Sonne:~/Projekte/Coccinelle/janitor> time /usr/bin/python3
>
Hello,
I constructed another multi-threaded TCP server for my needs
(based on the available software documentation).
https://docs.python.org/3/library/socketserver.html#asynchronous-mixins
I constructed also a corresponding script which should send nine record sets
(which get extracted from a
24 matches
Mail list logo
