[Import-sig] Imports with hooks not thread safe?

[Anthony & Janet Tuininga]

Thanks. But wouldn't it make more sense to acquire the lock around
__any__ import, regardless of whether it was hooked or not? Or would
that become too inflexible? Or would that cause potential problems with
existing code? I am really all that familiar with the core Python code
but that makes the most sense to me. Would you be able to give me some
insight? I agree that the exposing of the import lock would also solve
the problem but that would mean that all the import hooks would have to
do this in order to be thread safe. Or could it be placed in the core
imputils.py in the base class? Comments?

Anthony

On Sat, 2002-07-13 at 07:17, Gordon McMillan wrote:
> Anthony,
> 
> I've created a bug report on SF:
>  https://sourceforge.net/tracker/index.php?func=detail&aid=580952&group_id=5470&atid=105470
> 
> and assigned it to Tim for initial review. I'm
> suggesting that the imp module should grow
> acquire_lock and release_lock so hooks can
> do this right.
> 
> -- Gordon
> http://www.mcmillan-inc.com/
> 
> 
> 
> On 12 Jul 2002 at 15:00, Anthony Tuininga wrote:
> 
> > I just joined this list so my apologies if this has
> > been discussed before. The list (from the archives)
> > seems close to dead with a suggestion to kill it
> > permanently.... :-)
> > 
> > I noticed that in PyImport_ImportModuleEx, that a lock
> > is held until the import is completed or an exception
> > is raised. The only problem is that the higher level
> > interface PyImport_Import does __NOT__ hold the lock
> > and this is the method that is used for hooks. The
> > builtin function __import__ calls
> > PyImport_ImportModuleEx but if that function is
> > replaced with a call to a hook, no locking takes place
> > which makes the import mechanism not thread safe.
> > 
> > My question is: would there be a problem with holding
> > the lock during PyImport_Import? If there is, would
> > there be a problem with exposing a method that would do
> > the import lock? The only thing that is currently
> > available is imp.lock_held() but that simply states
> > whether or not the import lock is held and nothing that
> > I could see provides any mechanism for acquiring the
> > import lock.
> > 
> > I am using Installer (from Gordon McMillan) and it is
> > using its own locking mechanism which seems to break
> > inside PythonCOM (from Mark Hammond) if a large enough
> > quantity of threads are executing. All of my imports
> > are done within the import of the main module which is
> > done using the normal method but I would like to solve
> > this problem in a more permanent way as otherwise I
> > will have to fork Installer for our own internal use.
> > Blech.
> > 
> > -- 
> > Anthony Tuininga
> > anthony@computronix.com
> > 
> > Computronix
> > Distinctive Software. Real People.
> > Suite 200, 10216 - 124 Street NW
> > Edmonton, AB, Canada  T5N 4A3
> > Phone:	(780) 454-3700
> > Fax:	(780) 454-3838
> > http://www.computronix.com
> > 
> > 
> > 
> > _______________________________________________
> > Import-sig mailing list
> > Import-sig@python.org
> > http://mail.python.org/mailman/listinfo/import-sig
>