You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In a nutshell, pybind11 comes with two implementations of gil_scoped_acquire, let's call them "simple" and "non-simple". The current default non-simple implementation is known to be buggy from bug reports and inspection (PR #4216). My vote (as one maintainer) is to remove the non-simple version entirely, to stop sending users into traps, but nanogui depends on it. We need to find a way to avoid sending everybody but nanogui into traps, but ideally not break nanogui with the next release. One obvious option would be to make the simple version the default, but keep the non-simple version in pybind11 behind a define that nanogui could use, but then we still have to maintain the non-simple code and explain why it is there. In the long run my preference would be to transfer the non-simple code to nanogui, maybe with cooperating changes in pybind11, but we need to figure out what exactly is needed.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Hi nanogui maintainers, could you please participate in the discussion under pybind/pybind11#4216 & pybind/pybind11#4218?
In a nutshell, pybind11 comes with two implementations of
gil_scoped_acquire
, let's call them "simple" and "non-simple". The current default non-simple implementation is known to be buggy from bug reports and inspection (PR #4216). My vote (as one maintainer) is to remove the non-simple version entirely, to stop sending users into traps, but nanogui depends on it. We need to find a way to avoid sending everybody but nanogui into traps, but ideally not break nanogui with the next release. One obvious option would be to make the simple version the default, but keep the non-simple version in pybind11 behind a define that nanogui could use, but then we still have to maintain the non-simple code and explain why it is there. In the long run my preference would be to transfer the non-simple code to nanogui, maybe with cooperating changes in pybind11, but we need to figure out what exactly is needed.Beta Was this translation helpful? Give feedback.
All reactions