Is the particular focus of your code on getting the GIL released during longer method invocations? I don't have any sway with Boost or anything, so I'm just asking out of my own personal curiosities. When I first saw the message, without seeing the code, I was wondering if you might have coincidentally created a scope-lock kind of thing for acquiring the GIL in the first place.
On Sun, Dec 16, 2012 at 2:37 PM, John Zwinck <jzwi...@gmail.com> wrote: > I posted this to the Boost list, where it was suggested this list as a > next step. If you saw it there, the rest of this message is the same. > > There are many questions and example classes online for dealing with > Python's Global Interpreter Lock (GIL) using RAII. I think Boost.Python > should provide this functionality, rather than having users who build > hybrid C++/Python applications copy-pasting code from various places. I > was one of those users recently, and the code I developed to deal with it > is now public: > > https://github.com/jzwinck/**pccl/blob/master/**InterpreterLockGuard.hpp<https://github.com/jzwinck/pccl/blob/master/InterpreterLockGuard.hpp> > https://github.com/jzwinck/**pccl/blob/master/**InterpreterLockGuard.cpp<https://github.com/jzwinck/pccl/blob/master/InterpreterLockGuard.cpp> > https://github.com/jzwinck/**pccl/blob/master/test/** > InterpreterLockGuard.test.cpp<https://github.com/jzwinck/pccl/blob/master/test/InterpreterLockGuard.test.cpp> > > Comments in the header explain how to use it in the context of > Boost.Python, and contain a link to a wiki from which some of the code was > originally copied. > > Why add this to Boost? It's clearly code that a bunch of people need, > often people who are already using Boost.Python. It has a permissive > license, and I can re-license it if need be. And it depends on Boost > (mostly for thread-specific storage--I hope this dependency won't be seen > as a liability here, though it could be removed if needed). > > This particular implementation was used successfully in a few programs in > a commercial setting on Fedora and RHEL systems. It has some extra checks > that we found helpful compared to some of the versions you'll find posted > online. The code also builds and passes its tests with GCC on Mac OS X. > > I welcome any feedback regarding the suitability for inclusion in Boost of > this particular code and/or the concepts it implements. > > John Zwinck >
_______________________________________________ Cplusplus-sig mailing list Cplusplus-sig@python.org http://mail.python.org/mailman/listinfo/cplusplus-sig
