"Gordon McMillan" <gmcm@hypernet.com> writes: > > Working with a (same version) Python app is actually > a secondary worry. I'm more bothered that, for > example, Excel can't load 2 frozen servers which > use the same Python. A COM component is useless IMO if it restricts which other components you can use, or which client you use, and that's why I didn't allow inproc COM servers in py2exe up to now. But, since this problem doesn't occur with nonfrozen servers, it seems the import hooks are the problem. > > > I hope using the frozen module mechanism instead of > > import hooks will make this more tolerant. > > But where are those modules frozen? How do they > get installed in the already running Python? What > if mulitple sets of frozen modules (with dups) want > to install themselves? I hope one could extend the FrozenModule table in an already running Python by adding more stuff to it. Isn't there already code in cvs which allows this? > It ties into Martin's earlier comments about > threading models. It may be that the solution > lies in using COM's apartment threading, > instead of free threading. That way, the COM > server could have it's own interpreter state, and > the calls would end up in the right interpreter. > Maybe. > > But I don't understand the COM part well enough, > and Mark's stuff supports free threading, not > apartment threading. Last I checked, win32all registers the components as ThreadingModel = both. As I understand this, both STA and MTA is supported (STA = Single Threaded Apartment, MTA = MultiThreaded Appartment). So marking them as STA should be safe if it is needed. Maybe Mark can clear the confusion? > > I really brought all this up to try to widen the > scope from extension modules which can > easily grab an interpreter state and hold > onto it. > Thomas
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4