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

[Vladimir Vukicevic]

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, they need to go around the final call 
into C++, thus need to be inserted directly into invoke.hpp.  The 
changes aren't much, but I'm getting a crash-course in boost::python 
innards :)

Thanks,
    - Vlad