[C++-sig] Conversion of python files to C++ ostreams

troy d. straszheim troy at resophonic.com
Tue Apr 6 18:14:46 CEST 2010


Niall Douglas wrote:
> On 4 Apr 2010 at 19:29, troy d. straszheim wrote:
> 
>> The first main change was to gut a bunch of the old preprocessor gunk 
>> and replace with boost.fusion.  This would make my branch incompatible 
>> with Niall's threadsafety changes;  on the other hand, it would probably 
>> be much easier to implement them.  as<...> and scored overload 
>> resolution are built on top of the fusionization stuff.   I've removed a 
>> great many old workaround #ifdefs.
> 
> If I have to rewrite the patch because you have eliminated 
> preprocessor complexity then I am extremely happy!
> 
> Back in the day when I was first developing the patch there was a 
> discussion about how best to modularise the threading support such 
> that *any* threading system could be added. The upshot that I 
> remember (and I might add that my memory is definitely increasingly 
> rewriting itself with age) was that Boost was going to be getting its 
> own threading support module and then thereafter C++ itself. I have a 
> vague recollection of strongly criticising the POSIX thread API which 
> in my opinion is very poorly thought through, and then a discussion 
> erupted about how a proper threading API should look. Needless to 
> say, it all culminated in nothing.
> 
> I think, with hindsight, that we all were going at it wrong at that 
> time. What we *ought* to have been doing is an upcall mechanism such 
> that routine X is always called just before entering C++ space and 
> routine Y is always called just before entering Python space. That 
> way you get the best of all worlds.

Makes perfect sense to me, but I'm very new to the problem.  Help me out 
a bit...  What code of yours should I be looking at?  I found this:

http://aspn.activestate.com/ASPN/Mail/Message/c++-sig/1865844

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.   What 
is supposed to happen when python calls cpp, which calls python again? 
  How about with multiple interpreters?  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();
}

If you could indeed use those C linkage functions, how about having 
boost.python send boost::signals that cppland has been entered/left. 
(sanity check?)  This would support multiple receivers, 
connect/disconnect, all that stuff that comes with boost::signals.  This 
could compile out for singlethreaded versions.   You could even send, 
say, an enum value with the signal to indicate what was happening 
(instance_get,  instance_new, function_call) and get some kind of 
tracing ability out of it.  Thoughts?

Thanks in advance for your indulgence, again I'm new to the problem.

-t




More information about the Cplusplus-sig mailing list