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