on Wed Oct 05 2011, "Niall Douglas" <s_sourceforge-AT-nedprod.com> wrote:
> On 5 Oct 2011 at 7:21, Dave Abrahams wrote: > > What I was proposing was that the compile-time registry is identical > to the runtime registry. I don't even know what that means. > Hence the order of lookup so a lot of the simpler conversion can be > done inline by the compiler. But AFAICT there's really almost no advantage in that, and it adds special cases to the model. > Sure, the same system can be abused to have special per-compiland > behaviours. That's fine; a scoped registry would allow the same thing. When you have a bunch of independently-developed modules flying around it's more than likely that there will be "ODR violations" across different modules, and that should be OK as long as they don't try to exchange those types. > I personally have found that rather useful for working around very > special situations such as compiler bugs. I agree that you shouldn't > have two separate systems, and 99% of the time both registries need to > do the same thing. In my own code in fact I have a lot of unit tests > ensuring that the compile-time and run-time registries behave > identically. > >> > Imagine the following. Program A loads DLL B and DLL C. DLL B is >> > dependent on DLL D which uses BPL. DLL C is dependent on DLL E which >> > uses BPL. >> >> Jeez, I'm going to have to graph this >> >> A >> / \ >> B C >> | | >> D E >> \ / >> BPL > > You can't guarantee that Dave. It depends on what flags to dlopen the > end user uses. And on the OS, and on what order things are loaded in. I wasn't trying to make an assertion, just trying to picture what you were describing. > And right now, Python itself defaults to multiple BPLs. I wouldn't put it that way, not at all. Again, what happens depends on the platform and a lot of other factors. >> > Right now with present BPL, we have to load two copies of BPL, one >> > for DLL D and one for DLL E. They maintain separate type registries, >> > so all is good. >> >> That's not correct. Boost.Python was designed to deal with scenarios >> like this and be run as a single instance in such a system, with a >> single registry. > > http://muttley.hates-software.com/2006/01/25/c37456e6.html > > There are plenty more all over the net. Believe me, I'm fully aware of those problems, and note that your reference doesn't mention Boost at all. I happen to know that this very large project out of Lawrence Berekely Labs has been successfully using Boost.Python in multi-module setups with a single instance of the library, across many different platforms, for years: http://cctbx.sourceforge.net/ You should also take a look at this whole thread http://gcc.gnu.org/ml/gcc/2002-05/msg02945.html if you want to have a clear sense of some of the issues. >> > But what if DLL B returns a python function to Program A, which then >> > installs it as a callback with DLL C? >> >> OMG, could you make this more convoluted, please? > > No, it's a valid use case. Again, search google and you'll see. Lots > of people with this same problem. I'm sure it's a valid use case, and I'm also sure you can illustrate whatever problem you're describing with no more than two Boost.Python modules. >> > As I mentioned earlier, this is a very semantically similar problem >> > to supporting multiple python interpreters anyway with each calling >> > into one another. >> >> How exactly is one python interpreter supposed to "call into" another >> one? Are you suggesting they have their own threads and one blocks to >> wait for the other, or is it something completely different. > > Right now BPL doesn't touch the GIL or current interpreter context. > > I'm saying it ought to manage both, because getting it right isn't > obvious. Sure. > And once again, if program A causes the loading of two DLLs each of > which runs its own python interpreter, you can get all sorts of unfun > when the two interpreters call into one another. Again, what does it mean for one interpreter to "call into another"? -- Dave Abrahams BoostPro Computing http://www.boostpro.com _______________________________________________ Cplusplus-sig mailing list Cplusplus-sig@python.org http://mail.python.org/mailman/listinfo/cplusplus-sig
