Steve Dower added the comment: Mark: > CoInitialize will load a number of COM DLLs into the process, which isn't > free and will have some memory and performance costs for programs that don't > use COM. I see around 10 such DLLs loaded.
Very good point. Most of those should already be loaded in the OS, which reduces the cost, but it's still not free. Given some other work I've been trying to do to reduce footprint, this is definitely a step backwards :( > This may well break things like pythonwin until they also grow support for > the new param I expect that, which is why I'm only proposing it for 3.6 onwards. While adding support for a new major version of Python should be fairly cheap, it isn't entirely free and so it's the right time to add new complications. > I wonder why we don't just expose it and let it be called manually? Because that prevents us adding features to the core interpreter that require COM before a user could choose to initialize it. Also, that's the current state of the world, and this is a proposal to change it - hence I don't want to start with that as an assumption since it makes this whole discussion moot :) Nikita: > COM should be initialized on demand by C modules that need it. They might > need STA or MTA, it's their choice to make. And if the C module is the core interpreter (see issue26137 for an example of where this would be necessary)? If we require user code to initialize COM, this whole proposal is moot as that is the current state of the world and it does not require any changes to achieve. > COM using apps are very likely to be GUI apps and need STA main thread. MTA > by default makes no sense. Fair point. CoInitializeEx defaults to MTA, and pythonwin follows this, while IronPython defaults to STA (since COM initialization is unavoidable in their context), so the default we should use is not obvious. But I will mention that there are plenty of ways that COM is useful without writing a GUI app, so I don't think we should assume that only GUI apps are going to use it. > PS. AMSI ... Your PS is basically answered in issue26137 - I want to keep the discussion of the merits of AMSI separate from this issue :) Paul: > It seems to me that core code that needs COM can use it by wrapping the code > in CoInitializeEx(sys.coinit_flags)...CoUninitialize(). This doesn't work when COM objects have to be kept around. In the AMSI case, the threading model is irrelevant, but you need to keep reusing the same context for each call, which means you can't keep initializing COM (I tried it - it crashes, I believe because you get a new memory allocator and/or arena each time, but I didn't diagnose the crash thoroughly). There may be a workaround for cases where we can't keep reinitializing COM (add a background non-Python thread and do all the calls from there), but the complexity is fairly high and the performance impact is greater. Worth investigating further, since the general feeling seems to be against change. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27417> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
