Or consider object activation and deactivation. If a ghost is
shared among multiple threads, then __setstate__ could
be called from separate threads.
But, why should this be a problem? They would install the same
__setstate__ implementations are normally never written to be
thread-safe, and can leave the state temporarily insane /during/
construction; IOW, they expect to run "atomically", as does virtually
all code that isn't deliberately & carefully written to be
thread-safe. This goes deep; here's an example:
I believe I identified one cause for catastrophic thread-race
problems here (sharing a Connection across multiple threads, or
for any other reason sharing an in-memory persistent object across
non-serialized threads), even when objects are never modified. It
doesn't look shallow to me.
For more information about ZODB, see the ZODB Wiki:
ZODB-Dev mailing list - ZODB-Dev@zope.org