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
_______________________________________________
Cplusplus-sig mailing list
Cplusplus-sig@python.org
http://mail.python.org/mailman/listinfo/cplusplus-sig
