[C++-sig] Make threading support official

[troy d. straszheim]

Niall Douglas wrote:
> On 6 Apr 2010 at 12:14, troy d. straszheim wrote:
> Try 
> http://github.com/ned14/tnfox/blob/master/Python/BoostPatches.zip 
> which is about two years fresher.

Thanks.

> 
>> In that patch, why do you (un)lock in invoke.hpp instead of in
>>
>>    static PyObject* function_call(...)
>>
>> in function.cpp and the various other static C linkage functions that 
>> are registered directly with the Python C/API via PyTypeObjects?  At a 
>> glance, these seem the closest points to the language boundary.  
> 
> I am afraid that I do not remember why. It could have been out of 
> ignorance, or simply because the patch I used as a base did so there 
> as well. It could also have been that I had a very good reason such 
> as forcing an ABI incompatibility to prevent accidental mixing of 
> incompatible binaries or something, or perhaps it was a maintenance 
> issue or some question of exception safety. It's old code I am happy 
> to see replaced with something much better anyway.

I see some special handling in invoke.hpp for 
boost::python::objects::detail::py_iter_, maybe that has something to do 
with it.  If one did lock/unlock where I suggest above, one wouldn't 
have the necessary c++ type information to do such handling.   Google 
doesn't turn up much on this case...   hints?

[snip]
>> Would you also need to lock in e.g. object_protocol.cpp:
>>
>> void setattr(object const& target, object const& key, object const& value)
>> {
>>      if (PyObject_SetAttr(target.ptr(), key.ptr(), value.ptr()) == -1)
>>          throw_error_already_set();
>> }
> 
> Maybe I am missing your point, but surely all accesses to Python must 
> hold the GIL first, not least because the GIL also specifies the 
> current interpreter to use? (I know that you can get away with some 
> calls, but relying on this seems chardly xprudent).

Take function new_class(...) in src/object.cpp:  this is called during 
BOOST_PYTHON_MODULE(), and invoke.hpp doesn't know about it, therefore 
nothing would be locked.

[snip]
> In TnFOX I have a metaprogramming construct which assembles inline a 
> jump table of specialisations of classes between which at run time 
> can be dynamically chosen. Fairly amazingly, all major compilers 
> correctly elide table entries which cannot be chosen such that they 
> will remove the choice logic entirely if there is just one possible 
> choice, or the whole construct if there are none. This particular 
> construct is really useful in BPL actually because it lets you fake 
> stuff like setting at runtime arbitrary python code as a C (not C++) 
> API based sort function.

Could you point me at the code?

> Hence it may well be that a static signals and slots implementation 
> could be more appropriate in this situation. I guess I wouldn't know 
> until I run benchmarks. Your thoughts?

Thanks for the discussion.  I'm now thinking that the handling of these 
enter/exit "signals" emitted by boost.python shouldn't be coupled to 
boost::signals or anything else.  Seems cleaner and easier to provide an 
interface behind which one could put a simple lock/unlocker or something 
more complicated involving boost::signals if desired.

-t