16

Python 3.2 introduced a new GIL implementation by Antoine Pitrou which exposes the function sys.setswitchinterval.

When would changing this be useful, and why?

Matt Joiner
  • 112,946
  • 110
  • 377
  • 526

2 Answers2

6

One use will be to make sure that operation(s) run atomically, for example:

sw_interval = sys.getswitchinterval()
try:
    # Setting the switch interval to a very big number to make sure that their will be no
    # thread context switching while running the operations that came after.  
    sys.setswitchinterval(sys.maxint)
    # Expressions run here will be atomic ....
finally:
    sys.setswitchinterval(sw_interval)

Another use case will be to tune your code specially when you're facing the convoy effect (or any edge case where the new GIL give bad performance). Maybe (just maybe) changing the context switch interval can give you more speed.

Disclaimer: The first method cited above is considered dark magic and it's totally not recommended (the threading.Lock-likes are preferred in that use case). In general I don't think that changing the thread context switch interval is something to do under normal circumstances. I will paraphrase what Tim Peters already say about metaclasses: changing thread context switch interval is deeper magic than 99% of people are going to need.

Matt Joiner
  • 112,946
  • 110
  • 377
  • 526
mouad
  • 67,571
  • 18
  • 114
  • 106
  • When an application is IO bound, would you _increase_ or _decrease_ it? – Matt Joiner Sep 11 '11 at 11:06
  • 3
    @Matt: Actually having only IO bound threads doesn't give a problem because each time a thread execute an IO bound instruction it release the GIL , but the problem can be seen when using a IO bound thread with CPU thread as explained in this issue (http://bugs.python.org/issue7946) in a case like this (again) maybe decreasing the switch interval can lead to better performance because the IO bound threads will not have to wait much longer if they didn't block at all. – mouad Sep 11 '11 at 11:58
1

It's more consistent and predictable this way.

Before, the interpreter switched threads every time it completed N virtual instructions, where every instruction could take arbitrary long to complete.

gukoff
  • 2,112
  • 3
  • 18
  • 30