Tres Seaver wrote:
If this *were* a true module (see below), you would not be getting per-thread semantics from it; you would need to keep a mapping keyed by thread ID to get such semantics. I'd been told a while back that "each Zope thread has its own namespaces and therefore its own copy of any given module-level variable". Is this false (given what you say below about ExternalMethod implementations not being real modules)?
The files containing ExternalMethod implementations are not "modules", really, and so your expectations about module-level globals are not being met. Instead, the EM machinery "execs" the text of the EM file in a custom namespacee, and then extracts the code object from it.
I think you are headed into "build a product" territory here, unless you want your EM to monkey-patch its cache into an existing module somewhere. Ouch. "Build a product" isn't an option for us, for a whole bunch of reasons. I guess one way to deal with this, then, would be to put the module-level objects in *another* module and import *that*?
Does each Zope thread get its own copy of an imported module, or would I need to use something like Dieter's SharedResource to keep, say, a dict of connections keyed by thread id? Many thanks for your help Regards Ben