[C++-sig] Re: boost::python and threads

[Nikolay Mladenov]

Vladimir Vukicevic wrote:
> 
> Nikolay Mladenov wrote:
> 
> >>However, an alternative solution that I was thinknig of is to bake the
> >>thread smarts directly into boost::python.  It seems to me that
> >>call_method and similar should always be wrapped with a
> >>PyGILState_Ensure/PyGILState_Release.
> >>
> >>
> >
> >I guess you can do that without a problem?
> >
> Yeah, though I'm having a slight issue with call_method invocations
> where the return-type is void, since I need to split up the conversion
> and the actual "return r;" call.
> 
> >>Also, an additional call policy
> >>could be added, something like "allow_threads", which would cause b::p
> >>to call Py_BEGIN_ALLOW_THREADS and Py_END_ALLOW_THREADS around the
> >>function invocation on C++.  This seems like a much more generally
> >>useful solution than me trying to do the dance in wrapper classes.
> >>
> >>Is this the right way to go?  If so, I'd appreciate any pointers on
> >>implementing a new call policy, especially if it's possible to both
> >>specify allow_threads and a return_value_policy.
> >>
> >>
> >
> >Look here: http://boost.org/libs/python/doc/v2/CallPolicies.html
> >It should be very easy for you to write a call policy.
> >And than you can just use it like that
> >
> >return_value_policy<copy_const_reference, your_new_threading_policy>()
> >
> Whoops, I completely missed the overview concept page.. thank you, looks
> straightforward enough.  However, in looking at the code more, I don't
> think that a call policy would do it -- since no Py_* API functions can
> be called betwen BEGIN/END macros, 

I didn't see this in the python docs?


>they need to go around the final call
> into C++, thus need to be inserted directly into invoke.hpp.  

And how can you be sure that the c++ call won't call back to python?


>The
> changes aren't much, but I'm getting a crash-course in boost::python
> innards :)
> 
> Thanks,
>     - Vlad