race/deadlock when creating a multiprocessing.manager instance while importing a module ?

[pograph]

On Dec 15, 2:57 am, Sebastien Binet <seb.bi... at gmail.com> wrote:
> Dave,
>
> [..snip..]
> On Tuesday 15 December 2009 02:49:00 Dave Angel wrote:
>
> > Since I don't see any other responses, I'll give my guess, even though
> > I'm not very experienced with the multiprocessing module.
>
> > It's my understanding that threads may not be created or destroyed
> > during an import.  So you need to find a way to defer the creation till
> > the imports are done.
>
> yes, I figured this much and I already wrapped my module with a ModuleFacade
> object which has lazy properties attributes [1].
> this solves the problem of import my module, but if the module importing my
> module is itself being imported, I am back to square one.
>
> and my module is being used by many people.
>
> I guess I'd need at least a way to detect that somebody is trying to use the
> lazy properties of my module facade while an import is "still active".
> is there such a mechanism ?
>
> cheers,
> sebastien.
>
> [1]https://svnweb.cern.ch/trac/atlasoff/browser/Tools/PyUtils/trunk/pyth...
> --
> #########################################
> # Dr. Sebastien Binet
> # Laboratoire de l'Accelerateur Lineaire
> # Universite Paris-Sud XI
> # Batiment 200
> # 91898 Orsay
> #########################################

The document of multiprocessing says:
Functionality within this package requires that the __main__ method be
importable by the children. This is covered in Programming guidelines
however it is worth pointing out here. This means that some examples,
such as the multiprocessing.Pool examples will not work in the
interactive interpreter.