Thread local has no attribute _current_plan
See original GitHub issueI’ve been seeing an error in 7.0.0b3 resulting in the error AttributeError: '_thread._local' object has no attribute '_current_plan'
. Looking through a git blame seems to point to https://github.com/cupy/cupy/commit/b150b89701fa51bf218765bf3c280a77b20e82bf which introduced a thread-local variable to hold the current plan. If I’m reading correctly (I’m not that familiar with Cython) it looks like variable gets initialized during module initialization. This means that any new threads created by the user do not have the _current_plan
field (though they do have the _thread_local
variable).
It looks like the intention of the code may have been to set a “default” value to the thread local _current_plan
that could then be overwitten in a thread-local way. But that is not how Python thread local works (and I’m not aware of a way to make it work like that without adding a proxy object around it).
Can someone confirm the intention of the code, and whether a proxy object is an acceptable solution? If so I wouldn’t mind putting together a PR.
Conditions:
- CuPy 7.0.0b3. Does not repro in 7.0.0b1.
- Linux PPC64le
- CUDA 9.2.148
Sample stacktrace output:
File ".../conda/envs/myenv/lib/python3.6/site-packages/cupy/fft/fft.py", line 573, in fftn
func = _default_fft_func(a, s, axes)
File ".../conda/envs/myenv/lib/python3.6/site-packages/cupy/fft/fft.py", line 449, in _default_fft_func
curr_plan = cufft.get_current_plan()
File "cupy/cuda/cufft.pyx", line 16, in cupy.cuda.cufft.get_current_plan
File "cupy/cuda/cufft.pyx", line 22, in cupy.cuda.cufft.get_current_plan
AttributeError: '_thread._local' object has no attribute '_current_plan'
Issue Analytics
- State:
- Created 4 years ago
- Reactions:2
- Comments:8 (5 by maintainers)
Top GitHub Comments
Like I said before, I don’t know about Cython, but at least in regular Python, this is not the semantics of thread-locals:
I.e. a value set in the main thread will not be inherited by child threads. I do not know of a way (short of proxy objects) to achieve what the code currently seems to be doing.
Confirmed that the fix works in our original code base. Thanks all!