On Thu, Jan 22, 2009 at 9:09 PM, "Martin v. Löwis" <mar...@v.loewis.de> wrote: >> mrmmm... how? apps won't end up loading _both_ libpython2.5.dll _and_ >> python25.dll (or libpython2.N.dll and python2N.dll) will they? > > Of course they will!
yeah, silly - i worked that out juust after i pressed "send". > python.exe (say, the official one) loads > python25.dll. Then, an import is made of a ming-wine extension, say > foo.pyd, which is linked with libpython2.5.dll, which then gets loaded. > Voila, you have two interpreters in memory, with different type objects, > memory heaps, and so on. ok, there's a solution for that - the gist of the solution is already implemented in things like Apache Runtime and Apache2 (modules), and is an extremely common standard technique implemented in OS kernels. the "old school" name for it is "vector tables". so you never let the .pyd (or so even) modules "link" to the libpythonN.N.dll, pythonNN.dll (or libpythonN.N.so even), you _pass in_ a pointer to everything it's ever going to need (in its init<module>) function. > This was always the problem when an old extension module (say, from 2.4) > was loaded into a new interpreter (say, 2.5), then you load both > python25.dll and python24.dll, causing crashes. To prevent this issue, > Python now checks whether the module is linked with an incorrect > pythonxy.dll, but won't catch that libpython2.5.dll is also a VM. ok. i'll look at making libpython2.5.dll equal to python25.dll. >>> (of course, msvcr80 is irrelevant, because Python had never been using >>> that officially) >> >> oh? i saw the PCbuild8 and thought it was. oh that's even better - >> if python2.5 only officially support msvcrt whew. > > No, Python 2.5 is linked with msvcr71.dll. ehn? i don't see that anywhere in any PC/* files - i do see that there's a dependency on .NET SDK 1.1 which uses msvcr71.dll still, 71 is good news - as long as it's not involving assemblies. 2.6 is a different matter, but, thinking about it, i have hopes that the better-tested-codepath of the 2.6 codebase would have better luck with 9.0 [than i had with 2.5 and 8.0] simply because... it's been tested already! [and 2.5 with 8.0 hadn't] l. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
