()
| 150 | pass |
| 151 | |
| 152 | def f() : |
| 153 | |
| 154 | for i in range( 0, 100 ) : |
| 155 | o = IECore.Op( "", IECore.IntParameter( "result", "" ) ) |
| 156 | # The ClassWithDel class defines a __del__ method. |
| 157 | # This means that when it is deleted (when |
| 158 | # WrapperGarbageCollector::collect() calls Py_DECREF( o ) ) |
| 159 | # arbitrary python code gets run. This in |
| 160 | # turn means the interpreter might switch to |
| 161 | # a different thread. Which also might call |
| 162 | # WrapperGarbageCollector::collect(). Which |
| 163 | # will cause chaos if WrapperGarbageCollector::collect() |
| 164 | # isn't savvy to the possibility. |
| 165 | # |
| 166 | # In the wild it seems that this may be able to cause problems even |
| 167 | # without explicitly calling gc.collect() and RefCounted.collectGarbage(), |
| 168 | # but this test encourages things to go wrong by calling them regularly. |
| 169 | o.s = ClassWithDel() |
| 170 | if i % 10 == 0 : |
| 171 | while gc.collect() : |
| 172 | pass |
| 173 | IECore.RefCounted.collectGarbage() |
| 174 | |
| 175 | for j in range( 0, 10 ) : |
| 176 | threads = [] |
nothing calls this directly
no test coverage detected