Re: Registries

"Ralf W. Grosse-Kunstleve" <[email protected]> writes:

>> He links to the same copy of the Boost.Python shared lib that
>> package_b is using.
>
> Seems reasonable.
>
>> Your Tru64 case is a bit problematic, though.  If it's true that
>> there's no symbol isolation at all for extension modules which are not
>> otherwise linked to anything (I am having a really hard time believing
>> that's true), then just loading package_a and package_b at the same
>> time would cause problems (to say nothing of user U).
>>
>> Could you run a test on Tru64 with two trivial, traditional 'C'
>> extension modules?
>
> I remember that I got Boost.Python V1 cross-module inheritance
> partially working under Tru64, and only under Tru64. I also
> remember that I had serious trouble with the first version
> of V1 cross-module support under Tru64 even though each extension
> module was statically linked against libboost_python.a. My
> finding was this:
>
>   If two extension modules that are not dynamically linked against a
> common library (other than the system libraries) both define a
> symbol foo, the foo of the module dlopen'ed first will be used in
> both modules.

The system libraries are a common library.  I'm pretty sure there's no
distinction between a system library and other libraries.  Try static
linking the modules to any system libraries needed, if needed (but
try to avoid it).

Could you run a test on Tru64 with two trivial, traditional 'C'
extension modules?

> To get cross-module support to work on this platform I had to be
> creative (boost/python/cross_module.hpp):
>
>     friend T* from_python(PyObject* p, boost::python::type<T*> t, bool sig = fal
> se) {
>         return boost::python::detail::import_extension_class<T>::get_converters(
> )->from_python_Ts(p, t);
>     }
>
> Notice the "bool sig = false". The signature of the corresponding
> primary converter was just:
>
>     friend T* from_python(PyObject* p, boost::python::type<T*> t);
>
> Therefore the *mangled names* are different, resolving the ambiguity
> in the globally shared symbol space (phew!).
>
> Do you think it is fair to conclude from this experience that there is
> no symbol isolation?

Nope, not yet.

>>> I was thinking that scope().attr("__converter_scopes__") could be
>>> consulted. 
>>
>> What do you suppose scope() returns during the execution of a wrapped
>> function?
>>
>>       (hint: None)
>
> Oh. Makes sense. I guess I was partially blinded by wishful thinking.
>
>>> Do you mean time-wise or fundamentally?
>>
>> In order to implement what you want, wrapped functions would have to
>> store the scope in which they were wrapped somehow, and "set it up".
>
> Wow, sounds expensive. More than it might be worth.

I dunno, it doesn't really need to cost more than a pointer store.  As
long as users realize that the scope() becomes invalid the moment they
release the GIL, it just works.  However, I doubt that generalizes
well to lua; if multiple real threads are using the same interpreter
simultaneously you can't use a global variable to store any useful
state.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com