[Python-Dev] "Fixing" the new GIL

[Cameron Simpson]

On 14Mar2010 19:32, "Martin v. Löwis" <martin at v.loewis.de> wrote:
| > Speaking for myself, I have an app with a daemon mode which I expect
| > will sometimes behave as described; it answers requests and thus has I/O
| > bound threads waiting for requests and dispatching replies, and threads
| > doing data handling, which make constant use of the zlib library.
| 
| This is then already different from the scenario described. Every call
| into zlib will release the GIL, for the period of the zlib computation,
| allowing other threads to run.
| 
| > On the
| > client side the same app is often throughput bound by a data examination
| > process that is compute bound; I can easily see it having compute bound
| > threads and I/O bound threads talking to daemon instances.
| 
| I can't see that. I would expect that typically (and specifically
| including your application), the compute bound threads will synchronize
| with the IO bound ones, asking for more requests to perform.

In the single threaded case, sure. The usual command line "archive this"
mode fit this. But...

| That's the whole point of using the "bound" adjective (?): execution
| time is *bound* by the computation time. It can't get faster than what
| the computation can process.

If it's lurking behind a filesystem interface or in its daemon mode
(remote archive store), multiple client processes can be using it at once,
and it will be processing multiple tasks somewhat in parallel. Here one
can get a compute bound thread answering one request, impacting quick
response to other parallel-and-cheap requests.

Cheers,
-- 
Cameron Simpson <cs at zip.com.au> DoD#743
http://www.cskk.ezoshosting.com/cs/

Here was a man who not only had a ready mind and a quick wit,
but could also sing.    - _Rope_