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

[David Abrahams]

Nikolay Mladenov <nickm at sitius.com> writes:

>> 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?
>
>>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>()

I don't believe that call policies can do what he wants yet, since
there's no provision for state to be carried across the precall() and
postcall() functions as required by Py_BEGIN_ALLOW_THREADS and
Py_END_ALLOW_THREADS.

Some kind of redesign would probably be in order.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com