[Python-Dev] "Fixing" the new GIL
"Martin v. Löwis"
martin at v.loewis.de
Tue Mar 16 23:44:25 CET 2010
> You can't. This isn't an example where I am personally bitten by the GIL.
> I may be, but there's plenty of other stuff in terms of tuning or
> optimisation in my particular app before I get anywhere near the GIL.
> My point is not that it's biting me right now but that earlier you
> said the scenario was probably unrealistic, but I have an app which can
> probably exhibit exactly the issue under discussion.
I don't understand. First you say that there is plenty of other stuff
.... before you get anywhere near the GIL, and then you say that your
app can probably exhibit the issue under discussion. Which one is it?
I can easily believe that there is tons of other stuff that make the GIL
contention irrelevant, I can not believe that it will exhibit the issue
> | > 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).
> | Why do you say processing is in parallel?
> | In Python, processing is
> | normally never in parallel, but always sequential (potentially
> | interleaving). Are you releasing the GIL for processing?
> I mean that I can have multiple actual requests being served, and they
> are _not_ handled sequentially - the multi queue is to permit more than
> one to be in progress at once so that an expensive request need not
> inherently delay a following cheap request
But, in Python, due to the GIL, *everything* is sequential, *nothing* is
> Can't tell you - I'm not claiming the current GIL behaviour is biting me
> right now; I'm saying your claim that the scenario is unrealistic is a
> bit unfair; my app wil probably be just the kind of app to be affected,
> even only subtly. And it can hardly be alone in the "daemon" world.
Unfortunately, you are not able to demonstrate this (because the effect
would only be subtle).
My claim is that the scenario where the effect is *visible* is
unrealistic, i.e. that, in realistic scenarios, tons of other effects
actually lessen the problem.
More information about the Python-Dev