[Python-Dev] "Fixing" the new GIL
cs at zip.com.au
Tue Mar 16 06:34:45 CET 2010
On 15Mar2010 09:28, Martin v. L�wis <martin at v.loewis.de> wrote:
| > As for the argument that an application with cpu intensive work being
| > driven by the IO itself will work itself out... No it won't, it can
| > get into beat patterns where it is handling requests quite rapidly up
| > until one that causes a long computation to start comes in. At that
| > point it'll stop performing well on other requests for as long (it
| > could be a significant amount of time) as the cpu intensive request
| > threads are running. That is not a graceful degration in serving
| > capacity / latency as one would normally expect. It is a sudden drop
| > off.
| Why do you say that? The other threads continue to be served - and
| Python couldn't use more than one CPU, anyway. Can you demonstrate that
| in an example?
I have a FuncMultiQueue class which manages a pool of worker threads.
Other tasks can make requests of it by passing a callable (usually
obtained via partial()) to its .call(), .bgcall() or .qbgcall() methods
depending on how they want to collect the result of the callable.
The idea here is that one has a few threads receiving requests (eg a
daemon watching a socket or monitoring a db queue table) which then use
the FuncMultiQueue to manage how many actual requests are processed
in parallel (yes, a semaphore can cover a lot of this, but not the
asynchronous call modes).
So, suppose a couple of CPU-intensive callables get queued which work for a
substantial time, and meanwhile a bunch of tiny tiny cheap requests arrive.
Their timely response will be impacted by this issue.
Cameron Simpson <cs at zip.com.au> DoD#743
hybrid rather than pure; compromising rather than clean;
distorted rather than straightforward; ambiguous rather than
articulated; both-and rather than either-or; the difficult
unity of inclusion rather than the easy unity of exclusion.
- Paul Barton-Davis <pauld at cs.washington.edu>
More information about the Python-Dev