[C++-sig] Sharing Global Singleton instances across boost.python extensions (windows & unix)

[Niall Douglas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10 Oct 2003 at 15:01, Joel Gerard wrote:

> Thanks for the advice but I don't think I explained my problem very
> well (and after reading this post you'll think that to be a gross
> understatement). I'm not sure its all that off topic but I suppose it
> may be a general problem.  The filemapping idea doesn't seem to fit my
> problem.  Here's what I'm trying to do:

It's on topic in the sense that it's about C++ and Python which is 
what this mailing list is actually for. It's rare we get something 
more general than boost.python!

> As I understand it, Boost sets things up to create a Windows DLL that
> Python explicitly links to when you use "import" (ie. using
> LoadLibrary), and then does its magic with the init function etc.
>  So what happens for me now is that my app starts the memory manager,
>  fires up python and runs a
> script that uses my boost.python extensions, which are supposed to use
> my Memory Manager.  The MemoryManager (as well as some other
> singletons) are supposed to be global in scope so that the extensions
> use them.  What's the best way to proceed with Boost so that these
> globals really are globals?  I can hack it out in DLL world to make it
> work, but I also need to port this code to some kind of POSIXish
> platform, and I'm not sure if my design will work with SOs.

You need not worry about POSIX shared objects because these behave 
more like a static library than DLL's do. But it is important not to 
have anything depend on special DLL functionality eg; DllMain.

> First question: What is the best cross platform solution here?

Do you have a GUI, and if so what are you using to operate it?

> Second question: when you compile the application into which scripts
> will be embedded and link against python22.lib is the python library
> statically linked to my app (ie nothing like LoadLibrary("python.dll")
> is going on?)  That is, am I statically linked to the pythoncore, and
> not to some thin layer that loads python dynamically?

On Windows python is almost always a DLL. On Linux the default is a 
static library to my knowledge.

> Third question: can I recompile python and use Boost to statically
> link my extension modules to the Python core, and then statically link
> python to my app and will this solve my problem?

If I understand what you've said so far correctly, there is no reason 
why either a fully static build or an entirely DLL build should not 
work. The only caveat is that python must import a DLL or shared 
object so you'll need at least one of those (it could simply 
bootstrap back into the parent process) though I'm sure with the 
appropriate C API calls of python you could skip this too.

I would suggest you place your memory manager into its own library so 
it can be loaded by your app and BP extension library. Then put the 
maths and geometry libraries into their own DLL's too and then 
generate a BP library which links in those libraries in order to 
provide them to python.

This is a design choice. I chose it because DLL's compartmentalise 
your code and generally speaking are better for good design and an 
easier transition to unix when the time comes. However as I said, you 
could link everything statically into a large monolithic binary. 
Since all code shares the same process and thus the same address 
space, it can all see each other - though of course it may not be 
able to /find/ each other.

I note that you think because code lives in a DLL it is somehow 
separate from other code. This is the right mentality to have for 
good design but it's incorrect in reality - once a DLL is mapped into 
a process space, it's almost the same as being statically linked into 
the binary. Indeed on Linux the kernel invokes the linker to "finish 
off" the linking process.

BTW if you plan to move to POSIX eventually, I *strongly* suggest you 
do it sooner rather than later. If you develop for both platforms 
simultaneously, you'll encounter all sorts of traps which you can 
work around as they occur. If you do windows first, you'll find the 
porting effort later much much harder.

Cheers,
Niall





-----BEGIN PGP SIGNATURE-----
Version: idw's PGP-Frontend 4.9.6.1 / 9-2003 + PGP 8.0.2

iQA/AwUBP4c8KsEcvDLFGKbPEQJP2QCeKuJ6WExkM5bjrY4uWqDiU8UGuHwAn0k1
UyoMvAYe2n9TG1dDy+Dzm1PK
=Z5ed
-----END PGP SIGNATURE-----